Deployment gates
What it is
Deployment gates are automated or approval-based checkpoints in a release pipeline that pause a release before (pre-deployment) or after (post-deployment) a stage until specified conditions are met. If a gate fails, the release is held or fails rather than continuing to the next environment.
Why it exists
A pipeline that blindly deploys to production is dangerous. Gates let you enforce “is it healthy enough to proceed?” — checking live telemetry, approvals, and work-item status — before expanding a rollout or cutting over. They make release decisions data-driven and governed instead of blind or manual-only.
Key ideas
- Approval gate: a human (often a different team/role) explicitly approves before/after a stage.
- Azure Monitor / query-based gates: evaluate a metric/log query (e.g. error rate, latency) and pass only when it’s within threshold.
- Work item gate: require relevant work items/change-requests to be associated.
- Pre-deployment vs post-deployment: pre = “can we go to this stage?”, post = “did this stage come out healthy?” — post-deployment gates are key for progressive rollout decisions (canary/ring expansion).
- Retries & timeout: gates run repeatedly over a window (e.g. every N minutes) and fail if never satisfied.
How it fits
Gates are the control mechanism that turns a release strategy into practice — especially for canary and ring rollouts, where metrics decide whether to widen or stop the rollout.
Exam notes
- Gates can be pre-deployment or post-deployment and are configured per stage in a release.
- Types include approvals, Azure Monitor (metrics/logs), and work item gates.
- Post-deployment monitoring gates are what automate canary/ring expansion and enable safer continuous deployment.
Related
release-definition · canary-deployment · deployment-ring · cd · rollback-strategy
📘 Source: Microsoft Learn — Deployment Gate