Branch policies are crucial to ensuring the code quality of your team's work. They should be set on all shared/parent branches.
When a branch has a policy set on it, new code must be pull requested for it to be merged into the branch. Thus, it ensures the code is reviewed and scrutinized before it becomes part of the solution.
You must be a project administrator or have repository-level edit policies to set branch policies. (Click here for official documentation on permissions.)
Policy Configuration
To set our branch policies, we must first navigate to Repos > Branches in DevOps's left navigation pane. Once this is open, you will see your list of available branches. Select the three dots next to the branch name, and then select Branch policies on the drop-down that appears here.
Require a Minimum Number of Reviewers
We should require at least one other reviewer on each pull request. This gives reviewers a chance to find issues in the code. It is also a good idea to reset the approval status from the reviewers when new code is pushed to the pull request, as new issues may or may not be introduced when this happens.
Depending on the team size, you may also want to allow the person creating the pull request to approve their own code. This encourages the developer to review their own changes. If this is the case, the minimum number of reviewers should be at least 2.
Check for Linked Work Items
Checking for linked work items means that pull requests must-have items from the backlog linked to them before approval can occur. When you are looking at the details of the linked work item, there will be a list of linked PRs associated with it.
Check for Comment Resolution
If a reviewer has comments about the code being pull requested, these should be acknowledged and resolved before the pull request can be approved.
Limit Merge Types
Using squash merge only means that multiple commits from the merging branch are condensed into a single commit on the main branch. This makes the changes easier to track and allows for a clearer view of the branch history.
Build Validation
It is important to verify that the merging branch builds correctly and there are no errors before this new code becomes part of the main branch. When set to automatic, the build pipeline is triggered when the pull request is created and when new commits are introduced into this branch.
It is recommended that we have the build expire when the main branch or branch we are merging into has been updated to avoid collisions.
Here, we see that our pipeline has been successfully added to our build validation policy.
Automatically Include Reviewers
It is a good idea to automatically add developers to the pull request as reviewers. Thus one does not need to manually add a certain number of people to satisfy the minimum number of required reviewers every time they make a pull request. This could include the team lead of the project.
Adding reviewers on separate lines, as seen below, can be handy as we can switch certain reviewers on and off based on availability and holidays.
