Why Build pipeline basics in Azure? - Purpose & Use Cases

The Big Idea

What if your software could build itself perfectly every time, without you lifting a finger?

The Scenario

Imagine you have to prepare a complex meal for many guests by yourself, without any help or tools. You have to chop, cook, and serve everything step by step, remembering each detail and timing perfectly.

The Problem

Doing all these steps manually is slow and stressful. You might forget an ingredient, overcook something, or serve dishes late. Mistakes happen easily, and fixing them takes even more time.

The Solution

A build pipeline automates these steps like a smart kitchen assistant. It follows a clear recipe, runs tasks in order, and checks everything automatically. This saves time, reduces errors, and makes the process smooth and repeatable.

Before vs After

✗ Before

git pull
compile code
run tests
zip files
upload manually

✓ After

trigger:
  - commit
steps:
  - build
  - test
  - package
  - deploy

What It Enables

With build pipelines, you can deliver software faster and more reliably, just like serving a perfect meal every time without stress.

Real Life Example

A developer pushes code to Azure Repos, and the build pipeline automatically compiles the app, runs tests, and prepares it for deployment without any manual steps.

Key Takeaways

Manual builds are slow and error-prone.

Build pipelines automate and streamline the process.

This leads to faster, reliable software delivery.

Practice

1. What is the main purpose of a build pipeline in Azure DevOps?

easy

A. To manually test code changes

B. To store code in a repository

C. To automate the process of preparing code for deployment

D. To monitor user activity on a website

Solution

1. Step 1: Understand the role of a build pipeline

   A build pipeline automates tasks like compiling code and running tests when code changes.

2. Step 2: Identify the main goal

   The main goal is to prepare code automatically for deployment or further steps.

3. Final Answer:

   To automate the process of preparing code for deployment -> Option C

4. Quick Check:

   Build pipeline purpose = automate code preparation [OK]

Hint: Build pipelines automate code prep, not manual tasks [OK]

Common Mistakes:

• Confusing build pipeline with code repository
• Thinking build pipelines monitor user activity
• Assuming build pipelines are for manual testing

2. Which YAML snippet correctly defines a trigger for a build pipeline on the 'main' branch?

easy

A. trigger:\n branches:\n - main

B. trigger:\n branches:\n exclude:\n - main

C. trigger:\n paths:\n include:\n - main

D. trigger:\n branches:\n include:\n - main

Solution

1. Step 1: Understand trigger syntax in YAML

   The trigger block uses 'branches' with 'include' to specify branches that start the pipeline.

2. Step 2: Check each option

   trigger:\n branches:\n include:\n - main correctly includes 'main' branch under 'branches' and 'include'. trigger:\n branches:\n exclude:\n - main excludes 'main', which disables trigger on it. trigger:\n paths:\n include:\n - main uses 'paths' which triggers on file changes, not branches. trigger:\n branches:\n - main misses 'include' keyword, so syntax is incorrect.

3. Final Answer:

   trigger:\n branches:\n include:\n - main -> Option D

4. Quick Check:

   Correct trigger syntax includes branches: include [OK]

Hint: Use 'branches: include:' to trigger on specific branches [OK]

Common Mistakes:

• Using 'exclude' instead of 'include' to trigger
• Confusing 'paths' with 'branches' in triggers
• Omitting 'include' keyword causing syntax errors

3. Given this YAML snippet in an Azure build pipeline, what will be the output of the script step?

steps:
- script: echo Hello, Azure DevOps!
  displayName: 'Print greeting'

medium

A. No output, script step is missing

B. Hello, Azure DevOps!

C. script: echo Hello, Azure DevOps!

D. Print greeting

Solution

1. Step 1: Understand the script step in YAML

   The 'script' keyword runs the command given, here 'echo Hello, Azure DevOps!'.

2. Step 2: Identify the output of the echo command

   The echo command prints the text 'Hello, Azure DevOps!' to the pipeline logs.

3. Final Answer:

   Hello, Azure DevOps! -> Option B

4. Quick Check:

   Script echo output = Hello, Azure DevOps! [OK]

Hint: Script runs commands; echo prints text to output [OK]

Common Mistakes:

• Confusing displayName with output
• Thinking script keyword prints itself
• Assuming no output if displayName is set

4. You wrote this YAML snippet for a build pipeline but it fails to trigger on the 'develop' branch:

trigger:
  branches:
    include:
      - main
steps:
- script: echo Build started

What is the likely cause?

medium

A. The trigger only includes the 'main' branch, not 'develop'

B. The script step is missing a displayName

C. The echo command is incorrect syntax

D. The YAML indentation is invalid

Solution

1. Step 1: Analyze the trigger branches

   The trigger includes only the 'main' branch, so changes in 'develop' won't start the pipeline.

2. Step 2: Check other parts for errors

   The script step is valid without displayName, echo syntax is correct, and indentation looks fine.

3. Final Answer:

   The trigger only includes the 'main' branch, not 'develop' -> Option A

4. Quick Check:

   Trigger branches must include target branch [OK]

Hint: Check trigger branches include all needed branches [OK]

Common Mistakes:

• Assuming script needs displayName to run
• Thinking echo command syntax causes trigger failure
• Ignoring trigger branch filters

5. You want to create a build pipeline that triggers only when files in the 'src/' folder change on the 'release' branch. Which YAML snippet correctly sets this up?

hard

A. trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/**

B. trigger:\n branches:\n include:\n - release\n paths:\n exclude:\n - src/**

C. trigger:\n branches:\n exclude:\n - release\n paths:\n include:\n - src/**

D. trigger:\n branches:\n include:\n - main\n paths:\n include:\n - src/**

Solution

1. Step 1: Understand branch and path filters

   To trigger on 'release' branch and only when files in 'src/' change, include 'release' in branches and 'src/**' in paths.

2. Step 2: Evaluate each option

   trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/** correctly includes 'release' branch and 'src/**' path. trigger:\n branches:\n include:\n - release\n paths:\n exclude:\n - src/** excludes 'src/**' so it won't trigger on those files. trigger:\n branches:\n exclude:\n - release\n paths:\n include:\n - src/** excludes 'release' branch, so no trigger on it. trigger:\n branches:\n include:\n - main\n paths:\n include:\n - src/** triggers on 'main' branch, not 'release'.

3. Final Answer:

   trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/** -> Option A

4. Quick Check:

   Include branch and path filters to trigger correctly [OK]

Hint: Use both branches and paths include to filter triggers [OK]

Common Mistakes:

• Using exclude instead of include for paths
• Triggering on wrong branch
• Forgetting to specify paths filter