DevOps for your Organization – Part 5: Branch Policies
In the previous post, we created a basic build process for our demo project. In this post, I will be going through the steps for setting up a branch policies in Azure DevOps. By the end of this post, you will understand:
- What are branch policies
- What are they used for
- How to enforce a branch policy
What are Branch Policies
Branch policies are a way of enforcing requirements for merging into a branch. These policies exist to enforce code or process requirements that you may have on your project. These policies are meant to improve code quality, traceability of changes, and encourage collaboration. Some examples of branch policies include:
- Pull requests must be viewed by a set number of reviewers
- Pull requests must have work items associated with them
- All code in a pull request must build when merged with master
Branch policies can be required when you want them explicitly enforced, and optional when you want them to simply encourage good behavior. For example, you may require that at least two other developers review code before it is included in the master branch, but suggest that all pull requests require work items associated with it.
These requirements can be enforced on a per-branch or per-subfolder basis. This allows for more stringent requirements to be applied to more important branches (e.g. master branch, releases/* subfolder, etc.), while weaker rules cover short-lived or experimental branches.
Why Branch Policies
Branch policies are an excellent way to protect your branches from corrupting changes. Set up properly, all members of the development team will know that whenever they clone the master branch, they will be getting code that has been reviewed and tested. They know that they will be getting code that has had the eyes of senior developers. They will know that the code will build. The process they will need to go through to get their code in will be repeatable and transparent. All decisions that come out of the pull requests discussions will be available for the team to see, capturing why design decisions were made.
On the last 5 projects I’ve been brought on to migrate the team to DevOps practices, this is the development process I’ve instituted. The teams have had great success with the transition, noting better understanding of code written by others, as well as a way to trace changes through the system.
Azure DevOps makes setting up these policies a breeze. Additionally, they have great resources on adopting Git branching strategies and have written at length about their branching strategy.
How to Enforce a Branch Policy
Due to the fast (and always surprising) speed at which Microsoft is developing new features for Azure DevOps, I am hesitant to do my own walk-through. The rate that the offer new features, the screenshots may be obsolete in a month. In the interest of keeping this article more evergreen, I will link to Microsoft’s excellent documentation on their current and latest features. There you will find the steps on how to enforce a branching policy and all of the features they offer.
Let Us Help You Out!
Branch policies are a great way to protect your codebase and encourage open collaboration between team members. Code Vanguard has worked with clients of all sizes, helping them to use DevOps practices to accelerate their time to delivery. If you’d like Code Vanguard to help your organization with your DevOps process, feel free to reach out to us!
This post is part of the DevOps for your Organization series, where we walk through some basic steps you can take to move your organization towards the DevOps process. The full series can be found here. If you’d like Code Vanguard to help your organization with its DevOps process, feel free to reach out to us!