Azure DevOps: Pipelines That Hold

Kick a pipeline without leaving the terminal — branch pinned, no UI clicking.

az pipelines run --name {{pipeline_name}} --branch {{branch}} --org {{org_url}} --project {{project}}

Prerequisites:

az CLI + azure-devops extension; az devops login done

Run from:

Anywhere

Expected output:

Run queued; run id and URL printed

Success looks like:

Run appears in the pipeline history for the right branch

The "is it just me or is CI broken" check.

az pipelines runs list --org {{org_url}} --project {{project}} --top 5 --query "[].{id:id, pipeline:definition.name, result:result, branch:sourceBranch}" -o table

Prerequisites:

az CLI + azure-devops extension

Run from:

Anywhere

Expected output:

Table of the last five runs

Success looks like:

You can see at a glance what failed and where

The only force-push that belongs in muscle memory: it refuses to overwrite work you have not seen.

git push --force-with-lease origin {{branch}}

Careful: Never force-push a shared branch (main/develop) — this card is for your own feature branches after a rebase.

Prerequisites:

Branch rebased locally; you understand what the lease protects

Run from:

The repo

Expected output:

Push accepted (or refused because the remote moved — which is the feature)

Success looks like:

Remote branch now matches your rebased local branch

Follows Rule 7

One command instead of eleven portal clicks — per environment.

az pipelines variable-group create --name {{group_name}} --org {{org_url}} --project {{project}} --authorize false --variables placeholder=replace-via-keyvault-link

Careful: Leave --authorize false: groups authorized for every pipeline defeat the access model.

Prerequisites:

az CLI + azure-devops extension

Run from:

Anywhere

Expected output:

Variable group created (link it to the vault in Library → the group)

Success looks like:

Group exists, not auto-authorized for all pipelines

Follows Rule 3

From empty Azure DevOps org to a pipeline that builds an image, pushes to ACR, and deploys to a gated prod — including the two setup failures every new org hits.

Prerequisites:

Azure subscription with an ACR and a target (Container App / AKS / App Service); repo with a Dockerfile; org admin access

Permissions:

Project Administrator in ADO; Owner or User Access Administrator on the Azure resource group (to create the service connection identity)

Starting state:

A fresh org/project with the code pushed and no pipelines yet

Tools:

az >=2.60, git >=2.40

1. 1.CheckRequest the hosted parallelism grant FIRST

   New orgs have zero free hosted parallelism and the grant form (aka.ms/azpipelines-parallelism-request) takes days to process. File it before writing any YAML, or your first run will queue forever.

   Expect:

   Grant request submitted (or org already has parallelism)

   Verify:

   A trivial pipeline run actually starts an agent

   If it fails here… (1 known failure)

   Runs stuck on "waiting for an agent" with no error = no parallelism. See the attached failure note.

   ⚠ First pipeline run never starts: no hosted parallelism

   ##[error]No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form...

   Likely cause: Free-tier hosted parallelism is grant-only for new orgs (an anti-abuse measure) and nobody requests it in advance

   Fix: Submit the grant form (aka.ms/azpipelines-parallelism-request) and wait 2–3 business days, or buy a parallel job / register a self-hosted agent to unblock immediately.

2. 2.DoCreate the service connection with a workload identity

   Project settings → Service connections → Azure Resource Manager → Workload identity federation (automatic). Scope it to the resource group, not the subscription. Name it for the environment (rg-prod-deploy), and do NOT tick "grant access to all pipelines".

   Expect:

   Service connection verified green

   Verify:

   Verify button passes; access limited to the pipelines that need it

   If it fails here… (1 known failure)

   Push failures with 403 later usually mean the connection identity lacks AcrPush — see the attached failure note.

   ⚠ Image push fails 403 despite a green service connection

   unauthorized: authentication required / 403 on push, while az acr login and pulls work

   Likely cause: The connection's identity has no AcrPush role on the registry — "verified" only proves login, not authorization

   Fix: Grant AcrPush on the registry to the service connection identity (az role assignment create --role AcrPush ...). Re-run — no pipeline changes needed.

3. 3.DoWrite azure-pipelines.yml with build and deploy stages

   Stages: Build (docker build + push to ACR, tag = $(Build.SourceVersion)), DeployStaging (deployment job targeting the staging Environment), DeployProd (same job, prod Environment). The image tag built once is the artifact every stage deploys — no rebuilds downstream.

   Expect:

   YAML merged to main via PR

   Verify:

   Pipeline parses (dry validation in the editor) and the PR build passes

4. 4.DoCreate the Environments and gate prod

   Pipelines → Environments → new "staging" and "prod". On prod: Approvals and checks → Approvals → add the named approvers (min 1, ideally 2) and a timeout. This single screen is Rule 6 made real.

   Expect:

   prod environment shows an Approvals check

   Verify:

   A test run pauses at prod until approved

5. 5.RunRun it end to end
   ⌘1Run a pipeline from the CLIbash

   az pipelines run --name {{pipeline_name}} --branch {{branch}} --org {{org_url}} --project {{project}}

   pipeline_namebranchorg_urlproject

   Copy commandfill {{pipeline_name}}, {{branch}}, {{org_url}}, {{project}} to copy

   Expect:

   Build and staging deploy green; prod waiting on approval

   Verify:

   Staging URL serves the new build; prod deployment is in "waiting" state

6. 6.CheckApprove prod and verify the same artifact shipped

   Approve in the run view. When prod is green, confirm the image digest running in prod matches the digest staging verified — same artifact, not a rebuild.

   Expect:

   Prod serves the identical image digest

   Verify:

   Digest in prod == digest built in the Build stage

Success looks like:

A commit to main builds, pushes an image, deploys to staging automatically, and waits for human approval before prod

Rollback:

Redeploy the previous image tag from ACR via the same pipeline's re-run (the artifact is the tag — Rule 5); pipeline changes revert via git.

Implements Rule 4, Rule 5, Rule 6

${{ }} resolves at template compile time, $( ) at runtime, and $[ ] lazily at runtime. A ${{ }} referencing a variable set by an earlier task will silently be empty — it was evaluated before the run started. When a variable is mysteriously blank, check which syntax consumed it before checking where it was set.

Twice now the lease check refused a push because a teammate had fixed something on the "abandoned" branch. Plain --force would have erased their commits silently. The refusal is not friction; it is the entire point of the flag.