Inside VSTS

Software Configuration Management and TFS Version Control

Jeff walks you through how to configure Team Foundation Server for optimal software management.

• By Jeff Levinson
• 10/01/2007

SCM covers many different areas, but in this article I'm going to talk about how to structure Team Foundation Server (TFS) Version Control to give you the most flexibility in dealing with different situations. There are several well-known patterns for dealing with version control structures, so this article will address situations generically using a branch-by-quality structure for demonstration purposes.

A good branching structure lets you handle most situations with ease; a bad branching structure makes it difficult to handle the most basic tasks and can make change management difficult at best.

A Basic Branching Structure
Let's start with a basic branch structure (see Figure 1, below). In this structure, the root is Production. Production is branched to QA and QA is branched to development. This creates a parent-child relationship between the branches.

[Click on image for larger view.]

A typical way to do this in TFS is to create a Prod folder under the Team Project node in Source Control Explorer (SCE) and add your solution to this folder. Right-click the folder and select Branch. Branch it to QA and repeat the process to branch QA to Dev (checking in each branch as you go).

With this structure, the Production branch becomes a simple repository for released code. The QA branch is where all of the builds for testing and release originate and the Development branch is where active coding takes place.

Merge Down, Copy Up
In a perfect scenario, the developers write code on the Development branch. When you're ready to move to QA, you merge Development to QA. When code has passed user acceptance testing and is ready for release, you merge QA to Production and release the code that's already built and tested. (In other words, don't do another build -- use the code from the build drop location!)

The way you do this is important, though; you don't just merge Development to QA! Figure 2, below, shows the proper way to move code from one branch to another. 

[Click on image for larger view.]

First, perform a "merge down" -- that is, right-click the parent (QA) branch and select Merge. Set the Target as the child (Development) branch. This may seem counterintuitive, but the purpose of this is to ensure that if there are any conflicts, they're fixed on what's called the "softer" branch -- the branch where more change is occurring ("firmer" branches have less change). Continue to do a merge down from QA to Development until you get a message saying there are no changes to merge. Remember to check in after each merge and to do a build after each merge to make sure nothing broke.

Finally, do a merge from Development to QA -- a so-called "copy up" because there won't be any conflicts. Then the code in QA can go to the testing environment.

As a best practice, apply labels on the Dev branch before you merge up, and on the QA branch once you build and release the code to test. When you release code to production and merge from QA to Production, remember to label the QA and Production branches after the merges. Also, only label on the merge up.

Problems in Testing
Now, what happens if bugs are found during testing? Where do you make the fixes and what do you do if you've already started writing code for a new release?

The answer is dependent upon a number of things. How long is your test cycle? How long will it take to make the fix? Can the fix be delayed until the next release? Have you applied labels appropriately?

Figure 3, below, shows two different ways to handle this situation and assumes that you've been applying labels on your merges from the child branch to the parent branch. (Note that you can use shelving as an option such that developers do not check in code while code is under test. Once the code has been released to production, developers can then check in shelved code, but this depends on your release cycle.)

[Click on image for larger view.]

If you labeled the code before merging from Dev to QA you may want to go with the first option in Figure 3 -- take a hot fix branch from the Development label which contains the code promoted to test and, when you're done, merge the branch to QA. One issue with this approach is that it requires a baseless merge from hot fix (1) to QA. This can be done from the command line using tf merge /baseless. There are some issues in version 1 of TFS that make this a fairly time-consuming process.

For the second option, you can take a branch from QA, fix the code and merge it back to QA without doing a baseless merge. Finally, to get the hot fix back into the main development line, you can merge QA down to Dev and resolve any conflicts on the Development branch.