The pipeline, written down

The first part taught what a pipeline is: trigger, build, test, deploy, one shape on any platform. This part teaches where it lives. In Azure DevOps a pipeline is not a thing you click together in a portal and hope to remember — it is a file, azure-pipelines.yml, committed to the root of the repository it builds, sitting beside the code it ships. That single decision changes everything downstream. A file goes through pull request review, so a change to how you deploy gets the same second pair of eyes as a change to what you deploy. A file lives on a branch, so you can try a risky pipeline change on a feature branch and merge it only when it works. And a file has a history: git blame tells you who changed the retry count and when, and git diff shows you exactly what moved between the release that worked and the one that did not.

This is the same argument Class Twenty made about infrastructure — a resource you provisioned by hand is a resource nobody can reproduce — turned on the delivery machine itself. A pipeline clicked together in a portal is knowledge that lives in one person's memory and one afternoon's clicking; a pipeline in the repository is knowledge the whole team can read, review, and roll back. You already met this shape from the other side: GitHub Actions, in Classes Twenty-Two through Twenty-Four, put the workflow in .github/workflows as YAML for exactly these reasons. Azure DevOps makes the same bet with different nouns, and this part is largely you learning the nouns — because the instinct, pipeline-as-code, you already have.

A pipeline you can't diff is folklore.

Open an azure-pipelines.yml and you are reading a three-level nesting, top to bottom. A stage is a major phase of delivery — Build, Test, Deploy-to-Staging, Deploy-to-Production — and stages run one after another, each a natural place to put a gate. Inside a stage are jobs, units of work that each run on one agent; jobs in a stage run in parallel unless you make one depend on another. Inside a job are steps, which run in order on that agent and are the only level where actual work happens. A step is one of two things and no third: a script — a shell command you write inline — or a task, a pre-packaged unit like AzureCLI@2 that someone else wrote and versioned so you do not have to. Learn to say it as a sentence and you can read any file: stages hold jobs, jobs hold steps, and a step is a script or a task.

Pipeline (YAML)

A pipeline defined declaratively in a YAML file — conventionally azure-pipelines.yml at the repository root — that Azure DevOps reads on each trigger to build a run. Because it is a file under version control, the pipeline is reviewed, branched, diffed, and rolled back exactly like application code, rather than configured by hand in a portal and remembered.

If this scaffolding feels familiar, it should: it is the GitHub Actions vocabulary from Class Twenty-Two with the labels swapped. You are not learning a new idea, you are re-nouning one you already hold. The table below is the whole translation on one page — the thing to pin above your desk the first week on a team that ships on Azure DevOps.

Two mappings deserve a flag. Azure Pipelines has a level GitHub Actions does not foreground — the stage — which is where multi-phase delivery and the gates between phases live; you will lean on it the moment a deploy needs a staging step before production. And the @2 suffix on a task is its major version, pinned deliberately so a task author's breaking change cannot silently rewrite your deploy overnight — the same discipline you already apply to a package lockfile.

A pipeline file begins by saying when it should run, and Azure DevOps gives you two triggers that answer two different questions. The CI trigger, written trigger:, fires when commits land on branches you name — this is the "someone merged to main, ship it" path. The PR trigger, written pr:, fires when a pull request targeting those branches is opened or updated, so the pipeline runs against the proposed change before it merges and reports back on the PR. The distinction is the difference between validating a change and acting on one: pr: tells you whether the code is safe to merge; trigger: does something because it now has.¹

Then there is the step you do not write. In an ordinary job, the first thing a pipeline needs is your source code, and Azure Pipelines checks it out implicitly — a checkout: self is injected as the first step of every regular job, so the repo is already there when your script runs. You only write checkout explicitly when you want to change its behaviour or turn it off. There is one sharp exception worth carrying, because it catches people in exactly the place this part is heading: a deployment job does not clone the repo automatically. If your deploy steps need files from source, you must add checkout: self yourself.² A deploy that only calls an already-built artifact or the Azure CLI usually does not — and the pipeline in the next section is built so it does not have to.

trigger:

The CI trigger. Runs the pipeline when commits are pushed to the listed branches. Omit it and the default is to build on every branch; set it explicitly so main-line ships are deliberate, not accidental.

pr:

The PR trigger. Runs the pipeline against a pull request before it merges, and reports status back on the PR. This is your automated gate on the change, distinct from acting on the merge.

implicit checkout

In a normal job, checkout: self runs first without being written. In a deployment job it does not — add it by hand if the deploy needs source.

Here is a real, correct azure-pipelines.yml — small, but every line of it does a job on a live system. It triggers on main, builds a Node app in one stage, and deploys the result in a second stage through a gated environment, authenticating to Azure by a service connection named on the page with no secret anywhere in the file. Read it against the sentence from §2: stages hold jobs, jobs hold steps, a step is a script or a task.

# azure-pipelines.yml — committed at the repository root
trigger:
  branches:
    include: [ main ]      # CI: ship when main moves

pr:
  branches:
    include: [ main ]      # validate PRs targeting main

stages:
  - stage: Build
    jobs:
      - job: build
        pool:
          vmImage: ubuntu-latest
        steps:
          # checkout: self is implicit here — source is already present
          - script: |
              npm ci
              npm run build
            displayName: Install and build
          - publish: dist            # hand the build output forward
            artifact: warehouse

  - stage: Deploy
    dependsOn: Build
    jobs:
      - deployment: deployWarehouse
        pool:
          vmImage: ubuntu-latest
        environment: warehouse-production   # the gate lives here
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureCLI@2
                  displayName: Deploy build to the warehouse app
                  inputs:
                    azureSubscription: azure-prod   # a service connection, by name
                    scriptType: bash
                    scriptLocation: inlineScript
                    inlineScript: |
                      az webapp deploy \
                        --name basecamp-warehouse \
                        --resource-group basecamp-prod \
                        --src-path $(Pipeline.Workspace)/warehouse

Five things earn their place. The two stages run in sequence because Deploy declares dependsOn: Build, so nothing deploys unless the build succeeded. Each stage runs on a fresh agent, so the build output does not simply carry over — the build job publishes it as an artifact (publish: dist, named warehouse), and the deployment job's deploy hook downloads it automatically into $(Pipeline.Workspace)/warehouse, which is exactly the path the deploy command reads. Build once, ship that same built thing — never rebuild in the deploy stage. The deploy is a deployment job, not an ordinary one — that is what binds it to the environment named warehouse-production, which records a deployment history and is the object an approval will later hang on (that is 39f; here it is just the gated shape). The work is done by the AzureCLI@2 task, and its azureSubscription input names a service connection — a credential stored and scoped in Azure DevOps, referenced only by name. There is no password in this file, which is the entire point of the last paragraph of §1: because the file is diffable and reviewable, the thing you least want to leak must never be in it. The credential behind that name is exactly the case file's problem, and the last part of the track fixes it properly.

That is the whole ambition of this part, and it is not small. Hand the file in §4 to someone who has only ever clicked a deploy together and it is a wall of punctuation; hand it to you now and you can narrate it — this triggers on main, this stage builds, this deployment job deploys through a gated environment, this task authenticates by a named connection with no secret in the file. Every real Azure DevOps pipeline you meet is an elaboration of that same skeleton: more stages, more tasks, variables and templates factored out, but the same stages-jobs-steps spine holding it up. The rest of the track thickens the skeleton; it does not replace it.

And the skill is portable in the direction that pays. You did not learn "Azure DevOps YAML" as a closed dialect — you learned to map a delivery machine onto a file, which is the same move GitHub Actions asked of you with different nouns. An engineer who can walk into a repo, open the pipeline file, and read it aloud on the first morning is worth conspicuously more than one who needs the portal and the person who built it. That reading fluency is what this part hands you; the next one settles where all this actually runs.