This post is part of a series of articles on the new TFS Build vNext System.
Using the old xaml builds we had the ability to perform gated checkins. This is only available for TFVC projects and not for GIT projects, mainly because this concept of gated builds uses shelvesets which are not applicable when using GIT.
With the new vNext build definitions, the concept of gated builds is gone from the triggers tab for both GIT and TFVC based builds.So what about gated checkins for vNext builds?
In TFS 2015 and Visual Studio Online we now have the ability to gate commits made to GIT and much more using a feature called branch polices. This functionality is only available for GIT projects currently, it will be interesting to see if and how Microsoft supports this for TFVC. I want to take a closer look at these new features.
To enable branch policies go to the settings page for your GIT based team project, gear symbol in the top right corner, and select the ‘Version Control’ tab.
Select the branch you want to apply branch policies to and there you will see a page for the branch policy settings.
Lets look in more detail at what this offers us.
- We have gated builds! We can gate commits to the selected branch depending on the result of a build. Only vNext builds are allowed, xaml builds are not.
- We can also require every commit to our branch to undergo code review by one or more users and block any commit that isn’t explicitly approved by the reviewer.
- We can also define different reviewers for different parts of the code base, e.g. SQL, C# etc
That’s really cool but there’s one really important line at the top that states- ‘Enabling branch policies will require changes to be submitted using pull requests.‘ That’s really important, it forces us to change our entire workflow to use a pull request concept.
Enabling branch policies on a branch will disallow any explicit push to that branch. Try it, TFS will disallow it. Instead we have to control all commits to our branch via pull requests. Pull requests in TFS work in a very similar way to GitHub but without the explicit fork of the repo that GitHub uses.
Lets take an example: I would like to commit a change to master to implement a new feature around improving performance of our application. The pull request model forces me to branch master and make all my changes to that branch. When I am ready I can publish my branch to the repo (note how this differs from the GitHub workflow, in GitHub, I would publish my branch to my fork not to the main repo)
When I next log into the web portal, TFS will have detected this new branch and I will be prompted to create a pull request.
Next I can set some settings for the pull request and confirm. Note the pull request is setup to go from the branch ‘PerformanceImprovements’ to ‘Master’
Doing so will kick off any build you have configured in the branch policy as well as set up the thread to allow code review.
Note that creating the pull request does not mean the change is complete and all development is finished. It opens up the change to the rest of the team and allows for a fully collaborative workflow (just like GitHub). I am free to push more changes to the PerformanceImprovements branch as is any other developer.
The configured reviewer, in this case Arista, has the pull request assigned to her and she can comment on the change as well as add comments to the file differences as can anyone else on the team.
Once all code reviewers have signed off on the change (which may include ensuring it is rebased to master etc) and any configured builds have successfully passed, the pull request can be completed and the changes applied to master.
We then are given the option to delete the development branch (if it is no longer needed)
Branch policies is a pretty cool feature that allows a really open and collaborative workflow and encompasses much more than just gated builds. I would definitely recommend using the pull request model as a way to introduce more quality and openness and to your development process.
I would love to see this workflow supported for TFVC projects and It will be interesting to see if and how Microsoft does this.