Featured image

Why Branch Policies Matter in Azure Repos

In my experience managing Azure Repos for teams, branch policies have been a game changer for maintaining code quality and enforcing standards without slowing down developers. They act as guardrails, making sure important branches like main or release never get unchecked or unreviewed changes.

You can think of branch policies as rules you set on specific branches to require things like a minimum number of reviewers, successful builds, or linked work items before a pull request (PR) can be completed. Without these, it’s easy for code to slip through with bugs or without proper oversight.

Setting Up Minimum Reviewers

One of the first policies I configured was Require a minimum number of reviewers. This is straightforward but powerful: it mandates that a PR needs at least X approvers before it merges.

What Worked Well:

  • Setting this to 2 reviewers for main branch worked great to catch issues early.
  • Allowing requestors to approve their own changes was disabled to avoid conflicts of interest.
  • We enabled “Reset votes on push” so that if the PR author pushed new changes, previous approvals were cleared, ensuring everyone reviews the latest code.

Pitfalls:

  • Be careful with the option Prohibit the most recent pusher from approving their own changes. In some cases, this blocked approvals unexpectedly when multiple commits were pushed by the same user.
  • Make sure your team understands why approvals might reset on pushes to avoid confusion.

Enforcing Linked Work Items

Linking work items to PRs helps track why changes were made and ties code to business requirements. We enabled the Check for linked work items policy to require at least one linked work item for PR completion.

This improved visibility and made audits simpler. However, it required discipline from the team to remember linking work items before creating PRs.

Build Validation Policy

Build validation is essential to catch issues before merging. We configured a build validation policy that triggers a pipeline build on PR creation and on source branch updates.

Tips:

  • Use Automatic (whenever the source branch is updated) trigger to keep PR builds fresh.
  • Set the build policy to Required so PRs can’t be completed unless the build succeeds.
  • For busy branches, consider build expiration settings to avoid excessive builds when the target branch updates frequently.

Comment Resolution

The Check for comment resolution policy helped enforce that all PR comments are addressed before merging. This was crucial in our code review culture to avoid ignoring feedback.

One thing to watch out for: some developers found it frustrating when minor comments blocked merges. We balanced this by making it required only on critical branches.

Limiting Merge Types

To keep branch history clean, we limited merge strategies to only allow Squash merge. This produces a linear history and avoids merge commits that clutter logs.

How to set it:

  • Enable Limit merge types policy and allow only squash merges.
  • Communicate this clearly to the team so they understand why merge options are restricted.

Automatically Adding Reviewers

For code ownership and expertise, we used the Automatically include reviewers policy. For example, changes to certain folders automatically add the relevant team or individual as a reviewer.

This made sure the right people always saw the changes and reduced manual overhead.

Managing Bypass Permissions

Sometimes emergencies happen and you need to push directly or complete PRs without meeting all policies. Azure DevOps allows setting Bypass policies permissions scoped to users or groups.

Lessons Learned:

  • Use bypass permissions sparingly and audit usage.
  • Avoid granting at project or repo level unless absolutely necessary.
  • Educate teams on the risks of bypassing policies.

Using Azure DevOps CLI for Automation

We’ve automated policy enforcement via the Azure DevOps CLI, which is handy for applying consistent policies across multiple repos or branches.

Example: Setting minimum reviewers via CLI

az repos policy approver-count create --allow-downvotes true --blocking true --branch main --creator-vote-counts false --enabled true --minimum-approver-count 2 --repository-id <repo-id> --reset-on-source-push true

Using CLI scripts helps keep your infrastructure-as-code approach intact.

Path Filters for Granular Control

Many policies support path filters to apply rules only to parts of the repo. For example, you can require reviewers only on changes to /src/critical-module/*.

Some gotchas:

  • Paths must start with / or a wildcard for the filter to work.
  • You can exclude paths with ! prefix.
  • Order matters; filters apply left to right.

Final Thoughts

Branch policies in Azure Repos are essential for maintaining code quality and enforcing best practices, but they need to be tailored to your team’s workflow.

  • Start simple: require minimum reviewers and build validation on protected branches.
  • Expand to linked work items and comment resolution as your process matures.
  • Use path filters and automatic reviewers to reduce manual work.
  • Monitor and adjust bypass permissions carefully.

With these policies in place, your team can move faster with confidence, knowing that quality gates catch issues early and code reviews are thorough.

If you haven’t tried branch policies yet, I highly recommend enabling them on your main development branches today!