Branch policies are an essential part of the Git workflow and allow you to define rules to protect critical branches of development. In this article, I will tell you how to implement branch protection in Azure DevOps.
How to setup branch policies?
Sign in to the Azure DevOps portal, and navigate to the Repos page. Once there, choose Branches and click on the ellipsis icon on the right side of the branch that you want to protect. From the dropdown menu, click on Branch policies. It’s important to know that if there are already policies enabled, this branch will not accept any more changes unless they are made via a pull request.
On the settings page of the selected branch, you will have four policy types:
- Branch Policies
- Build Validation
- Status Checks
- Automatically included reviewers
Let’s dig into all of them, starting with Branch Policies.
In this section, you will find four different policies (disabled by default):
- Require a minimum number of reviewers
- Check for linked work items
- Check for comment resolution
- Limit merge types
Require a minimum number of reviewers
This basic policy enforces that a certain number of reviewers approve the pull request. If you enable this option, you can also access these settings:
- Allow requestors to approve their own changes: If enabled, the pull request’s creator may vote on its approval. Otherwise, he/she can still vote for its approval, but their vote will not be considered in the reviewer count.
- Prohibit the most recent pusher from approving their own changes: This configuration is very similar to the first one, but this includes a broader group of contributors. By default, everyone can commit and vote on the pull request’s approval. This option makes the pusher’s vote not count when there is a more recent push.
- Allow completion even if some reviewers vote to wait or reject: If enabled, the pull request can finish even if a reviewer rejects the changes.
- Reset code reviewer votes when there are new changes: If enabled, the votes of the code reviewers are reset when new changes are pushed to the source branch.
Check for linked work items
This policy allows you to require that every pull request has linked work items. This is especially useful when you are using Azure Boards for your work management.
Check for comment resolution
This policy is focused on the code review process and ensures that when a comment is made in the code review section, it must be resolved before a pull request can be completed.
Limit merge types
This policy lets you allow or disallow some merge types on your pull request.
- Basic merge (no fast-forward): All the individual commits in the pull request branch are preserved, and a new merge commit is created to unite the master branch and the pull request branch.
- Squash merge: This particular merge will take all the commits that made up the pull request (they will be discarded) and creates a single new commit with those repository contents.
- Rebase and fast-forward: Rebase will take each individual commit in the pull request and cherry-pick them onto the destination branch.
- Rebase with merge commit: The commits in the pull request are rebased on top of the destination branch. Then those rebased pull requests are merged into the destination branch.
If enabled, this policy evaluates the results of a new build every time a new pull request is created, or if changes are pushed to an existing pull request targeting the selected branch. If this build is not successful, the pull request can’t be completed.
To add a build validation, first, we have to create a new build pipeline in the pipeline section.
Once you have successfully created a new pipeline, go to the settings page of the branch and click on the plus icon to the right of Build validation.
In the window that appears, select the build pipeline that you have previously created. You can also set different configurations as triggers (to fire the pipeline whenever the source branch is updated manually), set policy requirements (define if the build must succeed or if it can fail in order to complete the pull request), and build expirations (to make sure that updates to your protected branch don’t break changes for open pull requests). To complete the policy, click Save.
Once the policy is completed, it will be visible under the build validation section. You can also add a new one and, of course, change or delete the one you have already defined. The Enable switch is required to fire the build automatically.
This branch policy allows you to add third-party services to participate in the workflow and block or allow your pull request based on its policy requirements.
This policy allows you to automatically include some reviewers for each of your pull requests based on the changed code paths. The Policy requirement configuration has two options:
- Required: the pull request can’t be completed until every reviewer for the path approves the changes, or at least one person in every group added to the path approves the changes.
- Optional: add reviewers automatically, but do not require their approval to complete the pull request.
The pull request is completed when all required reviewers approve the code.
So far, we have seen how you set the branch policies to a specific branch, but there is also a way to do this in a more generalized way.
To set the branch policies for multiple branches, go to Settings, click on Repositories policies, and scroll down to the Branch policies section. In this section, you can create project-wide branch policies. To do so, click on the plus icon and select if you want to apply these policies to the default branch or any branch matching a specified pattern.
Once you click on Create, you will be redirected to the Cross-repository policies settings page, where you can create exactly the same policies as before.
When a branch has policies applied, you will see an icon on the right of the name.
- Azure Repos official documentation: Protect your Git branches with policies — Azure Repos | Microsoft Docs