Lock a TFS branch through builds

September 22, 2016

One of the things that is necessary if you subscribe to the feature branching method of source control in TFS is that, once a release is cut, it needs to be locked. There are other reasons that you might want to lock a branch, but this was my specific use case when I came up with this.

There are a dozen ways to do this; you can simply delete the branch, you can remove check-in permissions; however, you could also create a custom build, which prevents check-ins. This isn’t perfect, but it does give you a lot more flexibility that some of the other options.


Create a new build definition:


Then remove all the standard components. As a base level, it probably looks something like this:


Now, set the build as a gated check-in for your branch, and the next time you try and check something into that branch, you’ll end up with a build failure:



The advantage of this method is mainly flexibility. When someone attempts to check into this branch, you execute a custom workflow; so you can send an e-mail, give a custom message, connect to an IoT device that administers a small electric shock, etc. You don’t have to blanket reject check-ins, you can call call the TFS API, interact with services; you could even implement some kind of rudimentary approval system for it.


There are a couple of issues with doing this: firstly, if someone tries to check into two gated branches at the same time, they are given the option of a build - as far as I’m aware, there’s no way around this (obviously this means that this solution is not water-tight). Although, again, one of the advantages of the flexibility, is that you could probably check for this in the build.

Profile picture

A blog about one man's journey through code… and some pictures of the Peak District

© Paul Michaels 2024