Branch Policies in Visual Studio Online

Branch policies in VSO allow you to set certain rules against branches in your Visual Studio Online git repos. They are more or less like gated check-ins which TFS has had since forever. Visual Studio Online supports the below policies by default:

• Changes must be submitted to a branch only via Pull Requests
• A build must complete successfully before changes can be merged to the destination branch
• Add certain reviewers if the pull request modifies files in certain paths in the repo

To know more details on the complete workflow involving pull requests on visual studio online, check this excellent post http://blogs.msdn.com/b/visualstudioalm/archive/2014/06/10/git-pull-request-visual-studio-online.aspx

Setting up branch policies

To setup branch policies login to your visual studio online account and navigate to the team project, which has the git repo you want to set the policy on. You will need to have administrator privileges on the team project to setup the policy. After you’ve navigated to your team project, click on the settings wheel icon on the top right corner, this will take you to the admin panel of your team project. Select the ‘version control’ tab, and on the left rail select the branch you want to set the policy on (master branch in my case), and click on ‘branch policies’ tab. Refer the figure below, the click points are highlighted in yellow.

 
 

Under ‘Automatically build pull requests’, select both check boxes. You will need to provide a build definition here which VSO will queue every time a pull request is submitted or updated with a new commit. The second check box, ‘Block the merge’, is actually optional, if you want to allow the merge even on build break, you can uncheck this. Though I’m not sure why you’d want to do that.

The next section, ‘Code review requirements’, allows you to control how changes can be submitted to master branch. The first check box, ‘Require code reviews using pull request’, ensures that any changes to master happen only via pull requests and no one is able to push their changes directly to master. ‘Allow users to approve their own changes’, allows to you add yourself as one of the reviewers and approve the changes, which is nuts really :-)

The last option, ‘Add a new path’, enables you to add reviewers optionally depending on the files involved in the commits. For scenarios where you really want Dave C to look at the changes if anyone modifies files under \kernel\base. It has support for wild chars as well.

After the policies are set, when someone tries to push their changes directly to master, they see this:

So what you need to do now, is move your changes to a feature branch, push that branch to server and create a pull request to merge the changes to master. This workflow is explained in the link shared above.

Now let’s say, the feature branch was pushed and a pull request was created, but the change list has a silly syntax error. You will see the branch policies show up in the right rail and a build will be queued for verification.

Since the pull request had a syntax error, the build will fail and attempting to merge the changes to master will be blocked.

The next step is to fix the build failure, add a commit to the pull request and make sure you have at least one approval from reviewers. As soon as you push your local branch to server, a new build will be queued automatically and the status updated.

To enhance this even further, you can improve your build definition by, let’s say, adding a unit test build step and a code analysis build step, to ensure that all unit tests pass, before the pull request can be accepted and merged into master.