Branch Policies for TFVC

Audience

Everyone

I have been working with a large customer in Norway that is moving to TFS whole sale and also needs to continue using a server based source control system for the time being. It would be awesome for them to be able to move to Git, however the codebase is currently incompatible. Work is ongoing to remove this issue, and many components will be able to move as soon as we can add Git repositories to a TFVC Team Project (in TFS 2015 Update 1). SO in the mean time we need a way to apply policies to particular branches.

[Download Tfvc Branch Policy]

image

What I wanted was something like the existing Branch Policy feature for Git but in TFVC. This would need to be done as a Checkin Policy for it to work, so I went looking for existing policies, of which there are many. I found that while I could use existing policies in combination with the “pattern” policy that is part of the TFS Power Tools, however it would be an ugly and unwieldly solution.

The customer has many projects as part of a single Team Project, and that would make it very difficult to manage many policies based on paths. We needed a consolidated and simple solution.

image

This is what I wanted, a list of branches on the left, coupled to a set of policies on the right. We can then extend the policies as we decide what is needed. However it was quickly identified that they often applied policies across multiple branches. Specifically they have a year based branching structure that is replicated through all of the components. So for “Product 2016” they also deploy “Component A 2016”. There are hundreds of components that make up the final Product so…

image

[Download Tfvc Branch Policy]

…I moved to a much simpler to implement regular expression model. We have a list of regular expressions, and then apply that regular expression to the list of pending changes to find out which ones should be applied. Now that we have a list of matching Branch Patterns I can then integrate through each of them and evaluate the Branch Policies. These policies can be applied to multiple branches (paths) that match a simple pattern and then failures can then be transformed into messages for the developer.

The goal is not to create a list of 100 things developers have to go do. There is an expectation of due diligence and competence expected of every coder, so you will not see a “must run tests before checkin”. The idea is that we want to make sure that folks with good intent don’t forget to do one of the big ticket items. Like builds, work items, code reviews, or production locks.

Current Policies that have been implemented:

  1. Branch Lock – There are many reasons that you might want to lock a branch, maybe you need to prevent changes to code without approval as you move towards a release. Whatever the reason you can specify that a chosen pattern is locked and what the optional bypass string is. The bypass string needs to be entered into the comment for the checkin. Simple and effective.
  2. Code Review – You must have at least one Code Review, and any Code Reviews need to have been successful
  3. Work Items – Require at least one work item first, then I will likley implement the ability to select the types of workitems that are required.

This is a start and you are welcome to send feedback to [bla] in the form of issues or requests. Give it a try and provide me with feedback. All feedback is good feedback 🙂 even if I don’t agree.

[Download Tfvc Branch Policy]

You should also feel free to contribute to this policy on GitHub where I will be happy to take pull requests.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin
Share on Redit

We dont have any dates for public classes right now. sign-up to be the first to know, or contact us for discounts or private training.

Read more
Martin Hinshelwood
As a DevOps consultant, Agile consultant, and trainer, I’ve worked with hundreds of companies to improve their software product development. It’s astonishing how many Scrum Masters lack even a basic understanding of Scrum, let alone the expertise required to support the teams they work with.A significant portion of Scrum Masters …
Martin Hinshelwood
As we progress deeper into the dynamic landscape of the 21st century, our long-established organisations, born of the Industrial Age and infused with a DNA of strict command and control, stand on shaky ground. These organisations strut with command-and-control bravado, erecting clear hierarchies in their stable inert markets where bureaucracy …
Martin Hinshelwood
In organizational development and team dynamics, Agile (as the Agile Manifesto delineates) and Scrum (as the Scrum Guide outlines) guide teams not by solving their problems but by illuminating the issues that demand attention. These frameworks aim to identify and spotlight the challenges within a team or organization’s processes, effectively …
Martin Hinshelwood
This week, I participated in a Scrum.org Webinar hosted by Sabrina Love (Scrum.org Product Owner) as well as my colleagues, Joanna Płaskonka, Ph.D. and Alex Ballarin to discuss the state of learning and how immersive learning is the future of training.You can watch the video below to hear what we …