Design and implement build and release pipelines
Pipeline anatomy
YAML pipelines are trigger/pr → pool/variables → stages → jobs → steps → tasks. Templates come in two flavours: template: includes reusable snippets, while extends: enforces a structure so teams cannot skip mandatory steps. Deployment jobs target an environment and use a strategy - runOnce (default), rolling or canary; a regular job cannot reference an environment. Environments carry checks: approvals, branch control, business hours, exclusive lock, invoke REST API, query Azure Monitor and required templates.
Triggers and flow
CI triggers support path filters. Scheduled triggers use cron syntax and only fire when the code changed since the last successful run. resources: pipelines creates pipeline-completion triggers; resources: repositories checks out additional repositories. dependsOn and condition control stage flow, and stage output variables are read through dependencies.<stage>.outputs.
Expressions and variables
${{ }} is evaluated at compile time (template names, pool, stage shape). $( ) is a runtime macro substitution. $[ ] is a runtime expression usable in conditions. Secret variables are not automatically mapped to environment variables, and stage-level variables override global ones.
Traps
- "Run only when
src/apichanges" → path filter, not a conditional task. - Confusing deployment job with a regular job, or environment checks with classic release gates.
- Assuming variable group secrets are visible in logs - they are masked, and masking is not encryption.
Rule of thumb
If a value must exist before the run is queued, use ${{ }}; if it is produced at runtime, use $[ ] with a condition.