Azure DevOps Pipelines YAML Basics

Introduction

Azure Pipelines allows you to automate the building, testing, and deployment of your code using a declarative pipeline definition. This guide introduces the fundamental concepts of defining your pipelines using YAML.

YAML (YAML Ain't Markup Language) is a human-readable data serialization standard. It's widely used for configuration files and in scenarios where data is being transmitted or stored between languages.

What is YAML?

YAML's design is based on common programming language data structures and its syntax is designed to be intuitive and readable. Key features include:

• Indentation: Used to define structure and hierarchy (like Python).
• Key-Value Pairs: Data is represented as a collection of keys with associated values.
• Lists/Sequences: Items in a list are denoted by hyphens.
• Human-Readable: Designed to be easily understood by developers.

Pipeline Structure

An Azure Pipelines YAML file defines a pipeline. A typical pipeline has the following top-level structure:

trigger:
  branches:
    include:
    - main
    - develop
  paths:
    include:
    - src/*
    - .azure-pipelines.yml

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: 'Build'
  displayName: 'Build the application'
  jobs:
  - job: 'BuildJob'
    displayName: 'Build current configuration'
    steps:
    - script: 'echo Building...'
      displayName: 'Run a one-line script'
    - task: displayName: 'Restore NuGet packages'
      inputs:
        command: 'restore'
        projects: '**/YourSolution.sln'

                

Triggers

Triggers define when a pipeline should run. You can trigger pipelines based on branch commits, pull requests, or specific paths changed in your repository.

Example:

trigger:
  branches:
    include:
    - main
  paths:
    include:
    - src/*

                

This trigger will run the pipeline for commits to the main branch that affect files in the src/ directory.

Stages

Stages are the highest level of the pipeline's structure. They represent a logical collection of jobs that run sequentially. For example, you might have a 'Build' stage, a 'Test' stage, and a 'Deploy' stage.

Example:

stages:
- stage: 'Build'
  displayName: 'Build the application'
  jobs:
  - job: 'BuildJob'
    steps:
    - script: 'echo Building...'

- stage: 'Test'
  displayName: 'Run tests'
  dependsOn: 'Build'
  jobs:
  - job: 'TestJob'
    steps:
    - script: 'echo Running tests...'

                

The dependsOn keyword specifies that the 'Test' stage will only run after the 'Build' stage has successfully completed.

Jobs

A job is a collection of steps that are executed on a specified agent. Jobs within the same stage can run in parallel or sequentially. Jobs in different stages run sequentially.

jobs:
- job: 'BuildJob1'
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: 'echo Job 1'

- job: 'BuildJob2'
  pool:
    vmImage: 'macos-latest'
  steps:
  - echo Job 2'

                

Steps

Steps are the individual tasks or scripts that are executed within a job. These can be built-in Azure DevOps tasks, custom scripts, or commands.

Common Step Types:

• script: Executes a shell script.
• task: Runs a pre-defined task from Azure DevOps (e.g., DotNetCoreCLI@2, AzureRmWebAppDeployment@4).
• bash, pwsh, cmd: Specific script execution commands.

steps:
- script: |
    echo "This is a multi-line script."
    echo "It will be executed in order."
  displayName: 'Multi-line Script Example'

- task: displayName: 'Publish Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'

                

Variables

Variables allow you to parameterize your pipeline, making it more flexible and reusable. You can define variables at the pipeline level, stage level, or job level.

variables:
  buildConfiguration: 'Release'
  vmImageName: 'ubuntu-latest'

pool:
  vmImage: stages:
- stage: 'Build'
  jobs:
  - job: 'BuildJob'
    steps:
    - script: 
                    
Note: You can also define variables in the Azure DevOps UI as pipeline variables or variable groups, which can then be referenced in your YAML.