How do you set up branch policies in Azure DevOps to enforce PR reviews and build validation?

Think of a building code inspector who checks every construction plan before approving it. Without the inspector, anyone could build anything — with the inspector, every change is reviewed for safety and quality. Branch policies in Azure DevOps are that inspector for your code.

Branch policies are rules configured on specific branches (typically main or release branches) that must be satisfied before a pull request can complete. They prevent direct pushes to protected branches, forcing all changes through the PR workflow. This ensures code review, automated testing, and compliance checks happen before code reaches production.

The key policies available are: Require a minimum number of reviewers (e.g., 2 approvals), Require linked work items (traceability), Build validation (automatically trigger a pipeline and require it to pass), Comment resolution (all PR comments must be resolved), Merge strategy (squash, rebase, or merge commit), and Automatically include reviewers (add specific people or teams based on file paths changed). Build validation is the most powerful — it runs your CI pipeline against the PR branch and blocks merge if tests fail.

At production scale, teams configure different policies per branch. The main branch requires 2 reviewers, build validation, and linked work items. Release branches require the same plus an additional approval from a lead. Feature branches have no policies, allowing developers to iterate freely. Teams also use path-based reviewer rules — changes to infrastructure/ automatically add the platform team as required reviewers, while changes to src/payments/ add the payments team.

The non-obvious gotcha is that branch policies only apply to pull requests, not to users with 'Bypass policies' permission. Admins and service accounts often have this permission for emergency fixes, but it should be audited. Also, build validation policies run against the PR merge commit (the result of merging the source into the target), not just the source branch — this catches integration issues that would not appear if you only tested the feature branch in isolation.