In my previous posts on Team Foundation Version Control (1, 2, 3, 4) I spent a lot of time providing background branching terminology and patterns and outlined some of the common drivers for implementing a branching regime in your version control repository.

One of the less common uses for branching (in conjunction with access control measures) is to enforce quality gates in the software development process. In this post I will discuss what a quality gate is, and how they can be implemented TFVC branching and security.

What is a Quality Gate?

A quality gate is simply a process hurdle that is put between the development team and shipping the product which is designed to prove that the product has achieved a certain set of quality critera. The kinds of things that are assessed in quality gates may include:

• General stability and completeness of the product.
• Percentage of test coverage on the codebase.
• Level of documentation provided.
• Results of a security assessment.
• Performance and scalability metrics.

Conceptually quality gates aren’t that far removed from the requirements that we spell out in design documents and hope get tested against but like most things execution makes all the difference. Quality gates are strategically placed throughout the life of a software project to help identify issues as early as possible and as close as possible to their cause and if the software doesn’t meet the quality gate criteria it can’t progress until the issues are fixed.

Because quality gates can have a massive impact on project progress they must be planned out in advance and all members of the development team need to know what criteria will be being assessed so that its not their code holding things up. It is a good idea to put them into the project plan and allow some slack to address any issues that are discovered.

Implementing a Quality Gate

While a quality gate may test for different things the key element from a version control point of view is setting restrictions so that only those teams that have successfully passed the quality gate can reverse integrate their code onto the main version branch.

The simplest way to do this is to tweak the default security settings in TFVC so that feature teams working on their own branch cannot merge onto the trunk. Before we embark on any permissions changing we should really think about the different categories of users we have in the system, in the scenario I have outlined above we have at least the following:

• The feature team.
• The build team.
• The integration team.

Out of the list above you may not have come up with yourself is the integration team. Assuming that the quality gate has been passed you want some kind of mechanism for identifying team members that will be performing the reverse integration work. The integration team is layed over the top of the build and feature teams.

Now – I would love to show you some screenshots, but as I am sitting on the bus typing this out I can’t get to my TFS box in the office so I will bullet point the steps that you need to take to get this working.

1. From the Team Project in Team Explorer, right mouse click and select “Team Project Settings” and then click on “Group Membership”.
2. Add three new Team Foundation Server Groups called “Feature X Team”, “Feature X Integration Team” and “Build Team” (note that “Feature X” is replaced by the name of the feature the team is working on).
3. Add the three teams that were created to the “[Team Project]\Contributors” group.
4. In Source Control Explorer remove the rights of the “[Team Project]\Contributors” from the root area node, note that contributors only have the top five or so rights in that list.
5. Grant the “[Team Project]\Build Team” group the same rights that the “[Team Project]\Contributors” team had at the root area node.
6. Grant the “[Team Project]\Feature X Integration Team” group standard contributor rights to the main branch (not necessarily the root) and to the branch that the feature team is working on.
7. Grant the “[Team Project]\Feature X Team” group standard contributor rights to the feature branch that they are working on.

Once you have completed this step, developers working on the feature branch should be able to develop independently on the feature branch and members of the integration team should be able to forward and reverse integrate freely.

You then need to decide whether members of the feature team are going to be permanant members of the integration group. It really depends on the level of trust the build team has that the feature team isn’t going to deliberately or inadvertantly reverse integrate onto the trunk without passing their quality gate – just remember when the going gets tough – quality seems to go out the window.

Maybe the group membership should be linked to the project schedule so when slips start occuring the team members are automagically removed from the group

Finally – by not being a member of the integration group the team members cannot forward integrate. This is fine if the members of the integration group are on the ball, but if you need individual team members to be able to perform a forward integration just grant them Read access at the team project’s root area.