Azure DevOps Cheat Sheet
Key concepts and YAML pipeline syntax for Azure DevOps Boards, Repos, and Pipelines used in CI/CD workflows.
Basic YAML Pipeline
Minimal build pipeline definition.
trigger: - mainpool: vmImage: 'ubuntu-latest'steps: - task: UseNode@2 inputs: version: '18.x' - script: npm ci displayName: 'Install dependencies' - script: npm test displayName: 'Run tests'
Multi-Stage Pipeline
Build and deploy stages with dependencies.
stages: - stage: Build jobs: - job: BuildJob steps: - script: npm run build - stage: Deploy dependsOn: Build condition: succeeded() jobs: - deployment: DeployWeb environment: 'production' strategy: runOnce: deploy: steps: - script: echo Deploying...
Variables & Templates
Reusable pipeline variables and templates.
variables: buildConfiguration: 'Release'extends: template: templates/build-template.yml parameters: configuration: $(buildConfiguration)
Azure DevOps CLI (az boards/repos/pipelines)
Common az devops extension commands.
- az extension add --name azure-devops- Install the CLI extension
- az devops configure --defaults organization=<url> project=<name>- Set default org/project
- az boards work-item create --title "Bug" --type Bug- Create a work item
- az repos pr create --source-branch feature --target-branch main- Open a pull request
- az pipelines run --name MyPipeline- Trigger a pipeline run
Core Concepts
Key core concepts to know.
- Boards- Work item tracking (Epics, Features, User Stories, Bugs, Tasks)
- Repos- Git repositories hosted natively with PR and branch policies
- Pipelines- YAML or classic CI/CD build and release automation
- Artifacts- Package feeds for npm, NuGet, Maven, and Python packages
- Environment- Deployment target (e.g. production) with approvals and checks
Parameterized Pipeline Template
Share a build/test/deploy skeleton across repos while letting each caller override key inputs.
# templates/build-template.ymlparameters: - name: configuration type: string default: 'Release' - name: runTests type: boolean default: truesteps: - script: dotnet build --configuration ${{ parameters.configuration }} displayName: 'Build' - ${{ if eq(parameters.runTests, true) }}: - script: dotnet test --no-build --configuration ${{ parameters.configuration }} displayName: 'Test'# caller pipelineextends: template: templates/build-template.yml parameters: configuration: 'Debug' runTests: false
Matrix Strategy & Parallel Jobs
Fan a job out across multiple runtime versions or OSes in parallel.
jobs: - job: Test strategy: matrix: node16: nodeVersion: '16.x' node18: nodeVersion: '18.x' node20: nodeVersion: '20.x' maxParallel: 3 pool: vmImage: 'ubuntu-latest' steps: - task: UseNode@2 inputs: version: $(nodeVersion) - script: npm ci && npm test
Environments with Approvals & Checks
Gate a deployment stage on manual approval or an automated business-hours check, configured against the environment resource.
stages: - stage: DeployProd dependsOn: DeployStaging jobs: - deployment: ProdDeploy environment: 'production' # approvals/checks configured on this Environment in the UI or via REST API strategy: runOnce: deploy: steps: - script: ./deploy.sh prod displayName: 'Deploy to production'# Register a check via az devops (once az devops extension supports it) or REST:# POST https://dev.azure.com/{org}/{project}/_apis/pipelines/checks/configurations?api-version=7.1
Variable Groups Linked to Key Vault
Pull secrets from Azure Key Vault into a pipeline without storing them in YAML or pipeline variables.
variables: - group: prod-secrets # variable group linked to an Azure Key Vaultsteps: - task: AzureKeyVault@2 inputs: azureSubscription: 'prod-service-connection' KeyVaultName: 'my-keyvault' SecretsFilter: 'DbPassword,ApiKey' RunAsPreJob: true - script: echo "Using secret length: ${#DBPASSWORD}" env: DBPASSWORD: $(DbPassword)
Pipeline Internals & Governance
Concepts that matter once a team runs many pipelines, not just one.
- Service Connection- Stored, scoped credential (Azure Resource Manager, GitHub, Docker registry) that pipelines reference by name instead of embedding secrets
- Branch Policy- Repo-level rule requiring PR review, passing build, or linked work item before merge to a protected branch
- Agent Pool vs Agent- Pool is a logical group of build agents (Microsoft-hosted or self-hosted); an agent is the actual VM/container executing jobs
- Deployment Group- Legacy target-machine grouping for classic (non-YAML) release pipelines to deploy to on-prem/VM fleets
- Artifact Retention Policy- Project setting controlling how long build artifacts and pipeline runs are kept before automatic purge
- YAML Pipeline Resources- 'resources:' block declares external dependencies — other pipelines, repos, containers, packages — consumable via downloadable artifacts
- Classic vs YAML Pipelines- Classic uses a visual designer stored server-side; YAML pipelines are code, versioned in the repo alongside the app
Use 'templates:' to extract shared pipeline steps into a separate YAML file so multiple pipelines stay consistent and DRY instead of copy-pasting stages.