You probably have been in a situation where you finished your task and ready to create a pull request, but for whatever reason you don’t want your changes to get through (For example, you want to merge your changes back into the main branch after the current release). A common behavior – or let’s say old fashioned way – is to put something like “DO NOT MERGE” or “WORK IN PROGRESS” in the pull request’s title. And as an unwritten rule you should write it in all caps :). In such a situation, you can draft a pull request instead of creating a pull request.
To Draft a Pull Request in Azure Repos, you need to choose “Create as draft” when you want to create a pull request.
If you look at the list of pull requests now, you will see your pull request marked with “Draft” token.
It’s a good practice to lock down your repo and put some branch policies in place to avoid merging unwanted codes and non-complaint branches and commits into your master branch. However, we’ve all been in that situation where something urgently needs a fix and for some reasons we can’t meet the branch policies. By using Azure Repos, you can give a special permission to a set of users to override and bypass branch policies when things are on fire.
Azure Repos allows your lead developers to bypass branch policies when they want to push code or complete a pull request when it’s needed. You just need to set the settings in your repo settings. Navigate to your repo’s security setting, select the group and role your super users belong to and set the bypass policies’s settings.
As a good practice we always branch out our feature branch from the main branch (E.g. master) and when we are done with the development, we send a pull request to merge changes back into the main branch.
Due to the fact that main branch always evolving and going ahead with changes from other branches, when it comes to merging back a feature branch to the main branch, changes could break the code. While we expect team members to update their feature branches with latest changes from the main branch before sending a pull request to reduce the risk of broken code, this is not working well at all the time.
This is why introducing continues testing into the pull request process removes the risk of broken code. This simply can be implemented in VSTS by adding a Build Validation as part of Branch Policies.
Navigate to list of branches, find your main branch and then select “Branch Policies”.
On the policies screen, click on Build Validations and add your build pipeline to the branch policies. Continuous test can be one of the steps in your build pipeline. You can make this policy Required or Optional.
You can also enable Test Impact Analysis (TIA) to reduce the testing and respectively building time.
You can fine more information about TIA here.