Checks and approvals with YAML environments
Design and implement checks and approvals by using YAML-based environments
Conditions let the pipeline author decide whether a stage runs. Checks let the resource owner decide whether a stage may consume their resource. That ownership split is the concept the exam tests.
Where checks attach
Checks are configured on resources, not on pipelines:
- Environments
- Service connections
- Agent pools
- Variable groups
- Secure files
- Repositories
A manual approval on the production environment therefore governs every
pipeline that deploys to it, including one written by a team that has never seen
your approval policy.
The five categories, in order
Within a category, checks run in the order they were created. Checks are re-evaluated on each check's retry interval, and if they have not all succeeded before the timeout, the stage does not execute. A terminal failure — someone rejecting an approval — stops the stage immediately.
Checks worth knowing by name
| Check | What it enforces |
|---|---|
| Branch control | The deployment may only come from permitted branches |
| Required template | The pipeline must extend a specified template — the technical enforcement behind "every pipeline must use our secure template" |
| Business hours | Deployment only within a stated window |
| Exclusive lock | Only one run at a time may proceed to the resource |
| Invoke Azure Function / REST API | Gate on an external system's answer |
| Query Azure Monitor alerts | Block the deployment if the target is currently alerting |
Exclusive lock runs last and is what prevents two concurrent releases from
colliding on the same environment. When lockBehavior is omitted,
runLatest is the default and only the latest waiting run acquires the lock;
sequential lets every waiting run acquire it in turn.
Environments give you more than a gate
An environment also provides deployment history per target. Environments
currently support VM and Kubernetes resources, but deployment-strategy support
differs by resource type: rolling currently supports VM resources only. That
is why deployment jobs target environments while ordinary jobs do not.
Primary sources
- https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals
- https://learn.microsoft.com/en-us/azure/devops/pipelines/process/environments
- https://learn.microsoft.com/en-us/azure/devops/pipelines/process/about-resources
- https://learn.microsoft.com/en-us/azure/devops/pipelines/process/resources
- https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs