Why governance belongs on the branch
The main branch is the one place where everyone’s work becomes shared reality. When it breaks, every engineer is blocked. When it receives an unreviewed change, that change can be in production the same day. Branch policies are the cheapest control available: they cost minutes of configuration and prevent a whole class of incidents.
They are also easy to get wrong in either direction. Too loose and policies are decoration. Too strict and engineers find workarounds or wait days for reviews. This page explains how we configure Azure Repos as part of our Azure DevOps consulting, building on the basics in our Boards and Repos setup page.
What good looks like
- Nobody pushes directly to main or release branches, including administrators in day-to-day work.
- Every pull request builds and tests automatically, and a failure blocks completion.
- Reviews are fast and meaningful: small pull requests, clear ownership, and a norm of replying within a working day.
- Sensitive paths such as infrastructure code, pipeline definitions and authentication logic get review from people who understand them.
- History is readable, with a consistent merge strategy and traceable work items.
How it works in practice
The core policy set
On main we typically enable the following:
- Minimum number of reviewers, with the author’s own vote not counting and a reset of votes when new changes are pushed, so approvals mean something.
- Build validation, pointing at a pipeline that runs restore, build, tests and static analysis on the merge result.
- Comment resolution, so open review threads must be resolved.
- Linked work items, if you want traceability to Azure Boards.
- Limited merge types, choosing squash or another strategy as the default.
Build validation is the policy that most improves quality. It should be fast, ideally minutes, because slow validation is the main reason teams request bypass. Template-based pipelines described in pipeline templates help keep the validation definition consistent across repositories.
Path-based reviewers and status checks
Automatic reviewer policies add a person or group when a pull request touches matching paths. We use this for the folders where mistakes cost most:
/infra/* -> platform-engineers (required)
/.azure-pipelines/* -> platform-engineers (required)
/src/Auth/* -> security-reviewers (required)
/docs/* -> no policy needed
External checks can be added as status policies. For example, a security scanner or a compliance bot posts a status on the pull request, and the policy blocks completion until it reports success. This is how teams add vulnerability scanning without changing every pipeline.
Permissions: the part people forget
A policy is only as strong as the permissions around it. Azure Repos has separate permissions for contributing to a branch, force pushing, and bypassing policies when pushing or completing a pull request. We remove force push and direct push from regular users and keep bypass to a minimal, named group. Permissions are set at the repository or branch level using groups rather than individuals, and are exported as code or documented so changes are reviewable. Repositories created later inherit the same defaults through project settings.
Branching model
Trunk-based development with short-lived branches suits most product teams: small pull requests merged daily behind feature flags. Release branches are useful when you support multiple versions or have formal release windows. We pick one, document naming conventions, and configure policies to match: strict on main and release branches, relaxed on personal feature branches.
Making pull requests easy to review
Policy is half the story. The other half is the shape of the change being reviewed. We encourage a pull request template stored in the repository, which prompts for the purpose of the change, how it was tested, and any rollout or rollback notes. Small, single-purpose pull requests get faster and better reviews. A rule of thumb we share with teams: if a reviewer cannot understand the change in about fifteen minutes, it should probably be split.
Protecting pipelines and infrastructure code
Pipeline definitions deserve special care, because a change to YAML can change what runs with deployment credentials. We route any change under the pipeline folder through platform reviewers, and combine this with checks on protected resources so that production deployments only run from approved branches. The same applies to Terraform and other infrastructure as code, where a reviewed plan is the artifact reviewers should see.
Measuring the process
We look at three simple measures: time from pull request opened to first review, time to completion, and the proportion of pull requests failing validation. Long first-review times usually point to unclear ownership. A high failure rate suggests flaky tests or validation that does not match local developer tooling. Both are fixable once visible.
Decisions and trade-offs
One reviewer or two? Two catches more but halves throughput for small teams. A team of five with two required approvals will spend a lot of time waiting.
Strict policies for everyone, or risk-based? We prefer risk-based: tight on infrastructure and authentication code, lighter on documentation and tests.
Azure Repos or GitHub for repositories? Azure Repos is perfectly capable and integrates directly with Boards and Pipelines. GitHub offers features such as native CODEOWNERS and a broader open-source ecosystem. If you are weighing a move, see our Azure DevOps to GitHub migration planning.
When not to buy this. For a solo developer or a throwaway prototype, a pull request process is overhead. Policies pay off with several contributors and a branch that matters.
Common failure modes
- Slow validation builds. Engineers push for bypass. Fix the build, not the policy.
- Rubber-stamp reviews. Huge pull requests get approved unread. We encourage small changes and set expectations.
- Orphaned policies. Policies applied to only one repository drift. Project-level defaults help.
- Hidden bypass rights. Inherited permissions often grant more than intended, so we audit effective permissions.
Delivery and handover
You receive configured policies on your key branches, a permissions model, a contributor guide and, where useful, scripts or Terraform that apply the same settings to new repositories. We also look at review metrics with you after a few weeks.
How to tell it is working
Main is rarely red, review turnaround is predictable, bypass is rare and explained, and incidents traced to unreviewed changes disappear. If you want your setup assessed, contact us.