Release pipeline basics in Azure - Commands & Configuration

Introduction

A release pipeline helps you automatically deliver your app updates to users. It takes your tested code and moves it through stages like testing and production without manual steps.

When you want to automatically deploy your app after code changes are tested

When you need to deliver updates to different environments like staging and production

When you want to reduce human errors by automating deployment steps

When you want to track which version of your app is running in each environment

When you want to quickly roll back to a previous version if a problem occurs

Config File - azure-pipelines.yml

azure-pipelines.yml

trigger:
  branches:
    include:
      - main

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '7.x'
    - script: dotnet build --configuration Release
      displayName: 'Build project'

- stage: Deploy
  dependsOn: Build
  jobs:
  - deployment: DeployJob
    environment: 'staging'
    pool:
      vmImage: 'ubuntu-latest'
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo "Deploying to staging environment"
            displayName: 'Deploy step'

This YAML file defines a simple release pipeline in Azure DevOps.

• trigger: Runs the pipeline when code is pushed to the main branch.
• stages: Defines two stages: Build and Deploy.
• Build stage: Compiles the app using .NET SDK.
• Deploy stage: Runs after build and deploys to the staging environment.

Commands

This command creates a new Azure DevOps pipeline using the YAML file. It connects the pipeline to your code repository and sets it to run on the main branch.

Terminal

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

Expected Output

Pipeline 'example-release-pipeline' created successfully.

→

--name - Sets the name of the pipeline

→

--yml-path - Specifies the YAML file defining the pipeline

→

--repository - Links the pipeline to the code repository

This command manually starts the release pipeline to run the build and deploy stages.

Terminal

az pipelines run --name example-release-pipeline

Expected Output

Run started for pipeline 'example-release-pipeline'.

→

--name - Specifies which pipeline to run

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

Terminal

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

Expected Output

[{"id":123,"status":"completed","result":"succeeded","createdDate":"2024-06-01T12:00:00Z"}]

→

--pipeline-name - Filters runs by pipeline name

→

--top - Limits output to the most recent run

Key Concept

If you remember nothing else from this pattern, remember: a release pipeline automates moving your tested code through stages to deliver updates safely and quickly.

Common Mistakes

Not linking the pipeline to the correct branch in the repository

The pipeline won't trigger automatically on code changes if the branch is wrong

Always specify the correct branch in the trigger section and when creating the pipeline

Skipping the deploy stage or not defining environments

Without deployment steps, the pipeline builds but never delivers the app to users

Include deploy stages with proper environment names to automate delivery

Running the pipeline without checking the build stage success

Deploying broken code causes failures in production or staging

Verify build stage completes successfully before deploying

Summary

Create a release pipeline YAML file defining build and deploy stages.

Use Azure CLI to create and run the pipeline connected to your code repository.

Check pipeline runs to monitor build and deployment status.

Practice

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

easy

A. To monitor user activity on a website

B. To automate the delivery of applications through different stages

C. To write code for applications

D. To store application data securely

Solution

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

   A release pipeline automates the process of delivering software through stages like testing and production.

2. Step 2: Identify the correct purpose

   Among the options, only automating delivery matches the release pipeline's function.

3. Final Answer:

   To automate the delivery of applications through different stages -> Option B

4. Quick Check:

   Release pipeline = automate delivery [OK]

Hint: Release pipelines automate app delivery stages [OK]

Common Mistakes:

• Confusing release pipeline with coding or monitoring tools
• Thinking it stores data instead of deploying apps

2. Which syntax correctly defines a stage in an Azure release pipeline YAML?

easy

A. stage:
- Build
jobs: []

B. jobs:
- stage: Build

C. stages:
Build:
jobs: []

D. stages:
- stage: Build
jobs: []

Solution

1. Step 1: Review YAML structure for stages

   In Azure pipelines, stages are defined under 'stages:' as a list with '- stage:' entries.

2. Step 2: Match correct syntax

   stages: - stage: Build jobs: [] correctly uses 'stages:' followed by '- stage: Build' and an empty jobs list.

3. Final Answer:

   stages: - stage: Build jobs: [] -> Option D

4. Quick Check:

   Stages list starts with 'stages:' and '- stage:' [OK]

Hint: Stages use 'stages:' then '- stage:' list items [OK]

Common Mistakes:

• Using singular 'stage:' instead of 'stages:'
• Placing 'stage' inside 'jobs' incorrectly
• Incorrect indentation or list syntax

3. Given this YAML snippet in a release pipeline:

stages:
  - stage: Test
    jobs:
      - job: RunTests
        steps:
          - script: echo Testing

What will be the output when this pipeline runs?

medium

A. It will print 'Testing' in the job logs

B. It will print 'echo Testing' literally

C. No output will be shown

D. The pipeline will fail due to syntax error

Solution

1. Step 1: Understand the script step in pipeline

   The 'script' step runs the command given, here 'echo Testing', which prints 'Testing'.

2. Step 2: Predict output

   Since the script runs successfully, the output 'Testing' appears in the job logs.

3. Final Answer:

   It will print 'Testing' in the job logs -> Option A

4. Quick Check:

   Script runs command, prints output [OK]

Hint: Script steps run commands and show output [OK]

Common Mistakes:

• Thinking script prints the command text instead of output
• Assuming syntax error without checking YAML correctness
• Expecting no output from script step

4. You have this YAML snippet in a release pipeline:

stages:
  - stage: Deploy
    jobs:
      - job: DeployJob
        steps:
          - script: echo Deploying
          - script: echo Done
        dependsOn: Build

What is wrong with this pipeline configuration?

medium

A. 'dependsOn' should be inside the stage, not inside jobs

B. 'dependsOn' must be a job, not a stage

C. The 'steps' section cannot have multiple scripts

D. The 'jobs' keyword is not allowed inside stages

Solution

1. Step 1: Locate 'dependsOn' usage

   'dependsOn' controls stage dependencies and must be placed at the stage level, not inside jobs.

2. Step 2: Identify correct placement

   In the snippet, 'dependsOn: Build' is incorrectly placed inside the job, it should be directly under the stage.

3. Final Answer:

   'dependsOn' should be inside the stage, not inside jobs -> Option A

4. Quick Check:

   'dependsOn' belongs to stage level [OK]

Hint: 'dependsOn' goes under stage, not job [OK]

Common Mistakes:

• Placing 'dependsOn' inside jobs instead of stages
• Thinking 'dependsOn' applies to jobs only
• Believing multiple scripts in steps is invalid

5. You want to create a release pipeline with two stages: Build and Deploy. Deploy should only run if Build succeeds. Which YAML snippet correctly sets this up?

hard

A. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

B. stages:
- stage: Build
dependsOn: Deploy
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

C. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying

D. stages:
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building

Solution

1. Step 1: Understand stage dependencies

   To run Deploy only after Build succeeds, Deploy stage must depend on Build.

2. Step 2: Check YAML for correct 'dependsOn'

   stages: - stage: Build jobs: - job: BuildJob steps: - script: echo Building - stage: Deploy dependsOn: Build jobs: - job: DeployJob steps: - script: echo Deploying places 'dependsOn: Build' under Deploy stage, correctly setting the dependency.

3. Step 3: Verify order and jobs

   Build stage is first, Deploy second, with proper jobs and steps defined.

4. Final Answer:

   Correctly sets Deploy to depend on Build -> Option C

5. Quick Check:

   'dependsOn' on Deploy stage = correct dependency [OK]

Hint: Use 'dependsOn' on Deploy stage to wait for Build [OK]

Common Mistakes:

• Reversing 'dependsOn' causing wrong execution order
• Omitting 'dependsOn' so stages run in parallel
• Placing stages in wrong order without dependencies