Run CI Pipeline with pull request
DevOps goal is to get features as fast as possible into production. In the same time have to guarantee the new features nothing goes wrong. In this post I am going to show how to protect the master branch with a policy that enforces a pull request (PR) and reviews. I will show how to run the CI Pipeline which I have created in my previous post which builds the solutions and runs all unit tests.
Protecting Master Branch with a Pull Request Policy
To create a new policy go to Project settings –> Repositories –> Policies –> Branch policies and there click the + button.
Create a new Branch Policy
This opens Add branch protection where you can select one of the two options. I select “Protect current and future branches matching a specified pattern” and enter master as the branch name. This means that this policy is only valid for the master branch. Then click Create.
Add a Pull Request Policy for the master branch
Remember that you should have a ReadMe file in the repository if not you can create it in the Github and do a pull request from DevOps. Otherwise no matches find for master branch.
then shows Branch Policies menu where you can configure your pull request.
Configuration of Branch Policy
First, set on Require a minimum number of reviewers and then Minimum number of reviewers 1. Check the checkbox: Allow requestors to approve their own changes. and then Check the checkbox When new changes are pushed and after that Check the checkbox Reset all code reviewer votes.
Microsoft recommends that two reviewers should check the pull request for the highest quality
Configure the minimum number of reviewers
Next, we require every pull request to be linked with a work item. There should never be code changes without a Product Backlog Items (PBI) or Bug ticket describing the desired changes. Therefore, this is required.
Check for linked work items
The third for Check for comment resolution
We want to see that all comments have been resolved on pull requests and we want to block pull requests from being completed while any comments are active. In my projects, always the creator of the comment resolves the comment and not the creator of the (Pull Request) PR.
Configure comment resolution
There are different merge strategies. Some use squash merges, some do rebase and some do just basic merges. I select squash merges which Creates a linear history by condensing the source branch commits into a single new commit on the target branch It is good to have a merge strategy and limit the pull request to your strategy.
Limit the merge types
Next step is : Build Valdation, press to + and fill and check as following image:
I have selected NetCore-ProductMicroservice-CI from the dropdown list which is the CI Pipeline to this project and set the Path to : /ProductMicroservice-DotNET-Core-Master/*
Build Validation
If build pipenline is empty it shall depend some permission in this case check the following:
- From within your project, select Pipelines > Pipelines. Select the All tab, and then select the more actions menu then Manage security.
- On the permissions dialog box, make sure the following Contributors permissions are set to Allow.
(Sometimes this shall solve problem but somtimes not)
Configure automatic Builds
Now we are in the most important part of the policy. I have add a build policy and select the previously created ProductMicroservice CI pipeline. You can find here. I have set /ProductMicroservice/* as path filter. The automatic trigger starts the build and any time changes are committed inside the ProductMicroservice folder and the build expires after 12 hours. This means if the pull request is not completed within 12 hours, the build has to be triggered again.
Test the Policy
Add a new unit test (in VS2019), commit the changes to the master branch, and push the changes. According to the policy on the master branch, It is not allowed to push changes directly to the master branch, as seen on the following:
Error: TF402455: Pushes to this branch is not permitted; you must do a pull request to update this branch
As we know the master branch is protected, we have to create a feature branch. I name this branch feature branch and push it to Github and it is fine. Now we have two branches in Github.
In Azure DevOps under Repos –> Files, you can see that Azure DevOps registered the changes and already suggest to create a new PR. Click on Create a pull request and you will get into a new window.
In the new window, click on ‘Create a Pull request’ button to Create a new Pull Request:
Add a title, and optionally a description, and work items (Product Backlog Items: PBI)
And the press to Create button as following image:
After the pull request is created, the build will kick off immediately, and also all other required policies will be checked. The build failed due to a failing test, no work item is linked and not all comments are resolved.
I fixed my unit test, added a link to the PBI and fixed the suggested changes from the comment. The comment creator resolved the comment and this enabled us to complete the pull request.
Completing the Pull Request
After that we can see PR creator can also select auto-complete to complete the pull request automatically when all required checks are OK. After the merge to master is completed, the CI pipeline automatically kicks off a build of the master branch.
Conclusion
In this post, we have discussed how to protect the master branch from changes in Azure DevOps. And add a branch policy to the master branch in Azure DevOps and how to test a build process to check if the solution compiles and check that all tests run successfully.
Code can be found on GitHub.
In my next post I am going describe, how to Build CI Pipeline for Docker in Azure DevOps
This post is part of Azure DevOps step by step.