Branch policies help to ensure that your source code is safe and that the entire development team is following the same set of standards for managing their code changes.
While policies can be set on any branch in the repository, you will almost always want to ensure that you have configured policies for the master branch, as this is the branch that should, at all times, hold your production-ready code.
As soon as you enable any branch policy, the following rules will be in place for the branch:
- The branch cannot be deleted.
- All commits to the branch must be done by completing a pull request.
A pull request is a request made by a developer to commit changes to a branch. Policies can be set up so that pull requests have to be approved by a certain number of people. Only when the pull request is approved can it be completed, which commits the requested changes to the branch.
There are a number of different branch policies that you configure, such as the following:
- Pull request approvals.
- Pull request comment resolution.
- Code reviewer sign-off.
- Enforcing allowed merge strategies.
- Building validation.
- Enforcing whether all code changes are associated with at least one work item. This ensures that you can trace back to why the code change was executed.
Each branch in a repository can have a different set of policies. Policies can be enabled/disabled/modified at any point in time.
Do you remember what else we set up in the previous recipes of this chapter? Well, since we just committed a change to the master branch, the following will also automatically happen:
- The build pipeline will build a new version of our application that contains the change we just made.
- The release pipeline will take that latest version and deploy it to a Docker container where it can be further tested.
Give it a bit of time and you should be able to check the results of the build/release pipelines.
By completing this chapter, you've now set up a full CI/CD development process! Great work!