Enforce Pull Request Reviews and Build Validation in Azure DevOps

You will open a pull request to the main branch and click Merge, only to find the button inactive. The reason: your team’s Azure DevOps branch policy requires approvals and a passing build before merges are allowed. This guide shows how to configure those requirements, verify they’re working, and recover if a policy blocks a merge in error.

Prerequisites for branch policy configuration

Before you begin, confirm you have the necessary permissions. Project Administrator or Repository Security Contributor permissions are required to modify branch policies. You will also need an existing Git repository with a main branch, a defined build pipeline (YAML) that triggers on pull requests, and at least two users who can serve as reviewers.

Required reviewer setup

Azure DevOps treats reviewers as users assigned to the branch policy, not as a group or team by default. Add the intended reviewers in the policy UI; they will receive notification when a pull request targeting the protected branch is created. The minimum number of reviewers setting determines how many of the added users must approve before the merge button becomes active.

Build validation configuration

Build validation ties a specific YAML pipeline to the pull request workflow. When enabled, Azure DevOps queues the pipeline on the pull requests source branch and blocks merge until the pipeline completes successfully. The pipeline must be configured to run on pull request events; typically this is achieved with a trigger or condition in the YAML file.

trigger: - main pr: branches include - main

Note: The above snippet illustrates a typical trigger configuration; the exact syntax depends on your pipeline template. The branch policy will reference the pipeline name, not the YAML content directly.

Expected behavior and verification

Once the policy is saved, any pull request targeting the protected branch will display the required reviewer widgets and a build validation status on the PR page. The merge button remains disabled until the following conditions are met:

• At least the minimum number of assigned reviewers have approved the pull request.
• The associated build validation pipeline has completed with a successful status.

If you attempt to merge without approvals or with a failing build, the merge button stays disabled and a tooltip explains the policy violation.

Recovery and override considerations

If a policy incorrectly blocks a merge, administrators can temporarily disable the policy via the Repos Branches Branch policies page. For emergencies, specific users can be granted an Override permission that bypasses all branch policies. Grant this permission sparingly and audit its use, as it allows any user with the permission to merge without reviewer or build checks.

After the underlying issue is resolved, re-enable the policy or revoke the override permission to restore the enforcement.

Verification checklist

1. Create a test pull request from a feature branch to main.
2. Confirm the PR page displays the required reviewer widgets and a build validation status.
3. Attempt to merge without approvals or with a failing build; verify the merge button remains disabled and a tooltip indicates the policy violation.
4. After obtaining the required approvals and a successful build, check that the merge button becomes active and the merge completes successfully.
5. Optionally, audit the pipeline run logs to ensure the build validation executed on the pull request source branch.

Limitations and practical checks

Policy inheritance: Changes to a parent branches branch policy can affect child branches unless explicitly overridden. Verify the scope before applying a policy to a branch with descendants.

Override permission risk: Users granted the Override permission can bypass all branch policies, which may pose a security risk. Grant this permission only to trusted personnel and audit its use regularly.

Reviewer availability: Setting the minimum reviewer count higher than available team members can stall development. Adjust the count based on team size and rotating availability.

To verify these limitations, review the policy inheritance settings on the branch policy page and consult the audit log for override events after they occur.

Comparing branch policy reviewers to Git Code Owners: Azure DevOps branch policies enforce merge gates through assigned reviewers and build validation, whereas Code Owners is a Git feature that automatically adds approval comments based on file paths. Both can be used together, but branch policies control the actual merge permission.