Quality and release gates
Design and implement quality and release gates
Gates live at two different boundaries, and confusing them is the usual mistake.
| Boundary | Mechanism | Owner |
|---|---|---|
| Into a branch | Branch policies | Repository administrator |
| Into an environment | Approvals and checks | Resource owner |
Branch policies — the merge gate
Applied to a protected branch, these can require: a minimum number of reviewers, linked work items, resolved comments, a successful build, and successful status checks from external services. They stop bad code entering main.
What they cannot do is govern deployment. A branch policy has no opinion about whether a release may reach production.
Checks — the deployment gate
Configured by the owner of the environment, service connection, agent pool, variable group or secure file. Because the resource owner sets them, a central team can impose a control on pipelines authored by teams that never see it.
The security-and-governance examples worth naming:
- Required template — enforces that consuming pipelines extend a hardened template.
- Branch control — only permitted branches may deploy.
- Query Azure Monitor alerts — refuse to deploy onto an unhealthy target.
- Evaluate artifact — apply policy to the artifact itself.
Shift left, but keep the gate
Fast feedback in the PR is cheaper than a failed release, so run unit tests, linting and dependency scanning at the merge boundary. Keep the deployment gate anyway: the merge gate proves the code was acceptable, the deployment gate proves this release, into this environment, right now is acceptable. They answer different questions.
Primary sources