Branch protection in Azure DevOps

Protecting Master Branch from Bad Pull Requests is big challenge now a days while working in a team.
You are working on git with distributed architecture. Where many team members are creating pull request and adding their code to MASTER/MAIN branch.
It is important to protect our master branch such that if some wrong code or failing build code or failing test code is pushed by some team member. Then you do not want to get that code pulled or merged in MASTER branch.

In this article I will explain you how can you protect git master branch from accidental merge of failing code from some pull request in your Azure Repos.

Issue: Creating Pull Request with Failing Build

Work on New Feature Branch

Create new feature branch and write some bad code so that build failed.

Build is failing in New Feature Branch

Notice your build is failing in local machine.

Go ahead and push your code in your feature branch.

Creating Pull Request to merge bad code

Follow steps to create pull request to merge this breaking code in master branch.

1. Go to git repository and click on Pull Requests tab.
2. Select Compare & Pull Request button.

3. Add comment and create pull request

Notice wrong code is merged in master branch even though its build is failing it got merged.

See build failed still code got merged. This is not desirable.

We want to not merge the code until its build is passing.

Protecting Master Branch in Azure Repos

In this example I will setup some policy assuming the code writer is admin. In real world you may have different group of people who are the code reviewers and code approvers.

Configure branch policies

Select Repos > Branches to open the Branches page in the web portal.

Locate your branch in the page.

Select the … button. Select Branch policies from the context menu.

Require a minimum number of reviewers

The basic policy requires that a code writer can review & approve the code with no rejections.

Check for linked work items

Require associations between pull requests and a work item to ensure that changes to your branch have work item management tracking.

Build Validation

Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed. Build policies reduce breaks and keep your test results passing.

If a build validation policy is enabled, a new build is queued when either a new pull request is created, or if changes are pushed to an existing pull request targeting the branch. The build policy then evaluates the results of the build to determine whether the pull request can be completed.

Choose the + button next to Build validation.

1. Select the Build pipeline.
2. Choose the type of Trigger. Select Automatic (whenever the source branch is updated)
3. Select the Policy requirement. If you choose Required, builds must complete successfully to complete pull requests
4. After 12 hours if master has been updated. This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
5. Enter an optional Display name for this build policy. This name identifies the policy on the Branch policies page. If you don't specify a display name, the policy uses the build pipeline name. Select Save.

Finally you will see the badge in the master branch which denotes that your branch has policy setup done.

Create Failing Build Pull Request After Branch Policy Applied

Now lets create a pull request with the code base where build is failing.

Notice build is failing locally

Now let me create a pull request and see if this code can be merged to master branch.

While creating pull request notice it automatically triggered the pull request build.

1. Assign some reviewer I will put my self
2. Don't link any task and notice build process started as soon as I create pull request.
4. Since I did not link task it is saying Work items must be linked since this was in the branch policy.
   After waiting some time notice our build failed which was expected
   
   
   Notice master branch is un-changed since the build failed.
   

Even though we link some task this build is failing so one of the rule is not satisfied and hence code will never merge to master branch. We successfully, protected our MASTER branch.

Lets create pull request with working code

1. First I will assign work item to at-least pass that rule.
2. 
   

Next it is asking that "Rupesh Tiwari" must approve

So lets approve this pull request as well.

Notice now only policy is failing is the build. Our build is failing.

Lets go to the source code and fix the code and check-in to the feature branch.

Notice Automatically, our build will be triggered on the same pull request.

Notice build succeed this time.

Complete the pull request I will select Squash commit

Once you complete merge then again it will trigger a build which will run in master branch.

Finally code will be submitted to master branch.

Can I push changes directly to a branch after a branch policy is configured?

No, If you try to directly change the master branch it will show error saying u must create pull request. Which is good protection.

Git Repo Tags

Notice for each successful merge to master we see tags are created.

Why do we see 2 build for one Pull Request

If we create/update a PR, it will create a Pull request build, this build will only trigger the release stage which enable the Pull request trigger. If we complete a PR, it will create a CI build, and this build will trigger the release stage which enable CD. That's how it is designed, because if

your PR is not finished, every time you update the code (assuming the code is incorrect), your deployment will be triggered by this PR build, then this deployment must be meaningless(because your code has not been modified to complete), it will bring extra trouble to your deployment. The logic we designed is that only when you complete this PR (all error codes are modified) will a CI build be generated in the merge phase, which will trigger the CD.

Reference

Improve code quality with branch policies

Why 2 Builds while protecting master branch

Conclusion

We successfully protected our master branch in the repo. However, the dis-advantage is now our builds are running 2 times for each pull request and merge to master. This is the sacrifice that you have to do in order to protect your branch.

---

Do You Want to become full stack developer?

If you want to become full stack developer and grow your carrier as Lead Developer/Architect. Consider subscribing to our full stack development training programs. We have monthly membership plans and you will get unlimited access to all of our video courses, slides, source code & Monthly video calls.

• Please visit www.fullstackmaster.net/pro to subscribe to All Access PRO membership.
• Please visit www.fullstackmaster.net/elite to subscribe to All Access ELITE membership. You will get everything from PRO plan. Additionally you will get access to monthly live Q&A video call with Rupesh and ask doubts and get more tips and tricks.

You bright future is waiting for you so visit today www.fullstackmaster.net and allow me to help you to board on your dream software architect/lead role.

---

Contact Details: Say to me!

• Rupesh Tiwari
• www.rupeshtiwari.com
• [e-mail]
• Founder of www.fullstackmaster.net