Azure Pipelines: YAML from Scratch

What is Azure Pipelines YAML?

The YAML hierarchy

Every Azure Pipeline follows this structure:

Pipeline
  └── Stages
       └── Jobs
            └── Steps (scripts or tasks)

Level	What It Represents	Runs On	Parallelism
Pipeline	The entire CI/CD workflow	N/A — container for stages	N/A
Stage	A major phase (Build, Test, Deploy)	A logical group of jobs	Stages run sequentially by default, parallel with dependsOn: []
Job	A unit of work assigned to one agent	One agent (Microsoft-hosted or self-hosted)	Jobs within a stage run in parallel by default
Step	A single command or task	On the job’s agent	Steps always run sequentially within a job

Minimal pipeline — single stage, single job

When you have a simple CI build, you can skip the stages and jobs keywords:

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - script: echo Hello, World!
    displayName: 'Run a simple script'
  - script: dotnet build
    displayName: 'Build the project'

Azure Pipelines automatically wraps this in a single stage (“__default”) and a single job (“Job”). This is fine for simple builds, but production pipelines almost always use explicit stages and jobs.

Full multi-stage pipeline

trigger:
  branches:
    include:
      - main
      - release/*

stages:
  - stage: Build
    displayName: 'Build and Test'
    jobs:
      - job: BuildJob
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: 'build'
          - task: DotNetCoreCLI@2
            inputs:
              command: 'test'
              arguments: '--collect:"XPlat Code Coverage"'
          - task: PublishBuildArtifacts@1
            inputs:
              PathtoPublish: '$(Build.ArtifactStagingDirectory)'
              ArtifactName: 'drop'

  - stage: DeployStaging
    displayName: 'Deploy to Staging'
    dependsOn: Build
    jobs:
      - deployment: DeployToStaging
        environment: 'staging'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo Deploying to staging...

Key observations:

• dependsOn: Build makes the Deploy stage wait for Build to succeed
• The deployment job type enables environment tracking and approval gates
• The environment keyword links the job to an Azure DevOps environment for governance

Trigger types

Triggers define when a pipeline runs. The exam tests all five types:

CI trigger (continuous integration)

Runs when code is pushed to specified branches:

trigger:
  branches:
    include:
      - main
      - release/*
    exclude:
      - feature/experimental
  paths:
    include:
      - src/**
    exclude:
      - docs/**

Path filters are powerful — a pipeline that only builds when src/ changes avoids unnecessary runs when you only edit documentation.

PR trigger (pull request validation)

Runs when a pull request targets specified branches:

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

Important distinction: CI triggers fire on push. PR triggers fire when a PR is opened, updated, or re-opened.

Scheduled trigger

Runs on a cron schedule:

schedules:
  - cron: '0 2 * * 1-5'
    displayName: 'Weeknight build at 2 AM'
    branches:
      include:
        - main
    always: true

The always: true flag means the pipeline runs even if no code has changed since the last run.

Pipeline trigger (pipeline completion)

Runs when another pipeline completes:

resources:
  pipelines:
    - pipeline: buildPipeline
      source: 'MyApp-CI'
      trigger:
        branches:
          include:
            - main

This is how you chain a CI pipeline to a CD pipeline — the deployment pipeline triggers when the build pipeline succeeds.

Manual trigger

Any pipeline can be run manually from the Azure DevOps UI or REST API. You can also disable automatic triggers entirely:

trigger: none
pr: none

This creates a pipeline that only runs when manually queued or triggered by another pipeline.

💡 Exam tip: trigger none vs trigger omitted

This is a common exam trap:

• trigger: none explicitly disables CI triggers — the pipeline never runs on push
• Omitting the trigger keyword entirely uses the default — which triggers on ALL branches

If you forget to add trigger: to your YAML, the pipeline runs on every push to every branch. Always be explicit.

Same applies to pr: — omitting it enables PR triggers on all branches (in Azure Repos). For GitHub repos, PR triggers are controlled by branch policies, not the YAML pr: keyword.

Connecting GitHub repos to Azure Pipelines

Azure Pipelines can build code from GitHub repositories. The connection requires:

1. Service connection — a GitHub service connection in Azure DevOps (OAuth or PAT-based)
2. Azure Pipelines GitHub App — installed on the GitHub organisation for deeper integration (check run annotations, PR comments)
3. YAML file in the repo — azure-pipelines.yml at the root of the GitHub repository

Once connected, Azure Pipelines receives webhook events from GitHub (push, PR) and triggers pipeline runs. Build status is reported back to GitHub as check runs.

Why choose Azure Pipelines for a GitHub repo? When the team needs Azure Pipelines-specific features — YAML environments with approval gates, multi-stage release pipelines, Azure Boards integration for work item linking, or when the organisation already has Azure DevOps for project management.

Steps: scripts vs tasks

Steps are the atomic units of work in a pipeline:

Script steps

- script: npm install && npm test
  displayName: 'Install and test'

• Runs a command on the agent’s shell (bash on Linux/macOS, cmd on Windows)
• Use bash: for cross-platform bash scripts
• Use powershell: or pwsh: for PowerShell

Task steps

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'

• Tasks are pre-built, versioned, reusable automation units
• The @2 suffix pins the major version — you get minor/patch updates but not breaking changes
• Available from the built-in task library or the Azure DevOps Marketplace

When to use which: Use tasks when one exists for your scenario (they handle edge cases, logging, and error handling). Use scripts for simple or custom commands where no task exists.

YAML vs Classic pipelines

YAML pipelines are the future — version-controlled, template-ready, and receiving all new features

Feature	YAML Pipelines	Classic Pipelines
Definition	Code in a YAML file stored in the repository	UI-based — configured through the Azure DevOps web interface
Version control	Fully versioned with Git — every change is tracked, reviewable, and auditable	Not version-controlled — changes are tracked in revision history but not in Git
Branch-specific	Different branches can have different pipeline definitions	One pipeline definition applies to all branches
Templates	Full template support — reusable stages, jobs, steps across pipelines	Task groups provide limited reuse
Multi-stage	Native — stages, environments, deployment jobs, approvals	Build and release are separate systems (build definitions + release definitions)
PR review	Pipeline changes go through PR review like any code change	No PR review — changes take effect immediately
New features	All new pipeline features are YAML-first	Maintenance mode — no major new features
Migration	Recommended for all new pipelines	Migrate existing Classic pipelines to YAML when feasible

💡 Scenario: Nadia's migration from Classic to YAML at Meridian Insurance

🏢 Nadia Petrov at Meridian Insurance inherited 47 Classic build definitions and 23 Classic release definitions. Dmitri (VP Engineering) wants everything in YAML for auditability — Elena (compliance) insists that pipeline changes go through the same approval process as code changes.

Nadia’s migration plan:

1. Export each Classic pipeline using the “View YAML” feature (Azure DevOps can generate YAML from Classic definitions)
2. Refactor — don’t just export blindly. Combine build + release into a single multi-stage YAML pipeline
3. Templates — extract common patterns (restore, build, test, publish) into shared YAML templates
4. Branch policies — PR review required on azure-pipelines.yml changes, so Elena gets her audit trail
5. Migrate incrementally — one pipeline per sprint, starting with the lowest-risk projects

Rashid (platform lead) handles the agent pool configuration. The YAML pipelines reference the same agent pools as Classic — no infrastructure changes needed.

Question

What is the Azure Pipelines YAML hierarchy?

Click or press Enter to reveal answer

Answer

Pipeline contains Stages. Stages contain Jobs. Jobs contain Steps. Stages run sequentially by default (parallel with dependsOn: []). Jobs within a stage run in parallel by default. Steps within a job always run sequentially. For simple pipelines, stages and jobs can be omitted — Azure Pipelines infers them.

Click to flip back

Question

What are the five trigger types in Azure Pipelines?

Click or press Enter to reveal answer

Answer

1) CI trigger — runs on push to specified branches. 2) PR trigger — runs when a pull request targets specified branches. 3) Scheduled trigger — cron-based scheduling. 4) Pipeline trigger — runs when another pipeline completes. 5) Manual trigger — run from UI or REST API. Each supports branch and path filters.

Click to flip back

Question

What happens when you omit the 'trigger:' keyword in Azure Pipelines YAML?

Click or press Enter to reveal answer

Answer

The pipeline uses the DEFAULT trigger, which fires on every push to EVERY branch. This is a common gotcha — if you want to disable CI triggers, you must explicitly write 'trigger: none'. Same for 'pr:' — omitting it enables PR triggers on all branches (in Azure Repos).

Click to flip back

Question

How do you chain a CI pipeline to a CD pipeline in Azure Pipelines?

Click or press Enter to reveal answer

Answer

Use a pipeline trigger (pipeline completion trigger). In the CD pipeline YAML, define a resources.pipelines section referencing the CI pipeline by name. Add a trigger block to specify which branches should activate the CD pipeline when the CI pipeline completes successfully.

Click to flip back

Question

What is the difference between a 'script' step and a 'task' step in Azure Pipelines?

Click or press Enter to reveal answer

Answer

Script steps run shell commands directly (bash, cmd, PowerShell). Task steps use pre-built, versioned automation units from the task library (e.g., DotNetCoreCLI@2). Tasks handle logging, error handling, and edge cases. Use tasks when one exists for your scenario; use scripts for custom or simple commands.

Click to flip back

Knowledge check

Knowledge Check

Nadia writes a new Azure Pipelines YAML file but forgets to include a 'trigger:' section. What happens when she pushes code to a feature branch?

AThe pipeline does not run because no trigger is definedBThe pipeline runs because the default trigger fires on all branchesCThe pipeline runs only if the feature branch has a branch policyDAzure DevOps shows an error because 'trigger:' is required

Check Answer

Knowledge Check

Kai wants his Azure Pipeline to run only when files in the 'src/' directory change on the main branch. Documentation changes in 'docs/' should NOT trigger a build. Which trigger configuration achieves this?

Atrigger: mainBtrigger with branches include main and paths include src/**Cpr with branches include main and paths exclude docs/**Dschedules with cron expression and branches include main

Check Answer

Knowledge Check

Meridian Insurance has a CI pipeline (Build) and a separate CD pipeline (Deploy). Nadia wants the Deploy pipeline to run automatically whenever Build succeeds on the main branch. How should she configure this in YAML?

AAdd a 'trigger: main' to the Deploy pipelineBUse a pipeline completion trigger in the Deploy pipeline's resources section referencing the Build pipelineCAdd a post-deployment gate in the Build pipeline that triggers DeployDConfigure a scheduled trigger in the Deploy pipeline to run every 5 minutes and check for new artefacts

Check Answer

🎬 Video coming soon

Next up: GitHub Actions: Workflows from Scratch — master GitHub’s CI/CD platform with events, jobs, matrix strategies, and reusable workflows.