Build pipeline basics in Azure - Commands & Configuration

Introduction

A build pipeline automates the process of turning your code into a working application. It helps catch errors early and makes sure your app is ready to run every time you change the code.

When you want to automatically check your code for mistakes after every change.

When you need to create a ready-to-use app package without doing it manually.

When you want to save time by running tests and builds automatically.

When you want to share your app with others quickly and reliably.

When you want to keep your app updated with the latest code changes.

Config File - azure-pipelines.yml

azure-pipelines.yml

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
  displayName: 'Use Python 3.x'

- script: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt
  displayName: 'Install dependencies'

- script: |
    python -m unittest discover
  displayName: 'Run tests'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'
  displayName: 'Publish artifacts'

trigger: Runs the pipeline on changes to the main branch.

pool: Uses a Linux machine to run the steps.

steps: Defines the tasks: set Python version, install dependencies, run tests, and publish build results.

Commands

This command creates a new Azure DevOps build pipeline using the YAML file in the repository. It sets up the pipeline to run on the main branch.

Terminal

az pipelines create --name example-build-pipeline --repository https://github.com/example/repo.git --branch main --yml-path azure-pipelines.yml

Expected Output

Pipeline 'example-build-pipeline' created successfully.

→

--name - Sets the name of the pipeline

→

--repository - Specifies the Git repository URL

→

--branch - Specifies the branch to trigger the pipeline

→

--yml-path - Points to the pipeline YAML file

This command starts a manual run of the build pipeline to test if it works as expected.

Terminal

az pipelines run --name example-build-pipeline

Expected Output

Run started for pipeline 'example-build-pipeline'. Run ID: 123

→

--name - Specifies which pipeline to run

This command shows the latest run of the build pipeline so you can check its status and results.

Terminal

az pipelines runs list --pipeline-name example-build-pipeline --top 1

Expected Output

[

  {

    "id": 123,

    "status": "completed",

    "result": "succeeded",

    "sourceBranch": "refs/heads/main"

  }

]

→

--pipeline-name - Filters runs by pipeline name

→

--top - Limits the number of runs shown

Key Concept

If you remember nothing else from this pattern, remember: a build pipeline automatically checks and prepares your app every time you change your code.

Common Mistakes

Not specifying the correct YAML file path when creating the pipeline.

The pipeline won't run because it can't find the instructions to build your app.

Always use the --yml-path flag with the exact path to your azure-pipelines.yml file.

Triggering the pipeline on the wrong branch or forgetting to set triggers.

Your pipeline might not run when you expect it to, missing important code changes.

Set the trigger section in the YAML to the branch you want to monitor, like 'main'.

Skipping the test step in the pipeline.

Errors in your code might go unnoticed and cause problems later.

Include a test step to catch issues early before publishing artifacts.

Summary

Create a build pipeline using a YAML file that defines steps to prepare your app.

Run the pipeline manually to check it works and view the results.

Use triggers to automate the pipeline on code changes to keep your app updated.

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