Inside TFS

Branch by Quality using TFS 2010 (Part 1)

Mickey Gousset discusses the theory behind the Branch by Quality branching/merging pattern in Team Foundation Server 2010.

• By Mickey Gousset
• 10/21/2010

Branch By Release in TFS 2010

Branch By Release in TFS 2010 - Part 2

Branch By Release in TFS 2010 - Part 3

In this column, we are going to begin examining a popular branching/merging pattern, called Branch By Quality. This pattern is one of the most popular branching patterns used, and can serve as a base pattern for more complex branch strategies. After we look at the theory behind Branch by Quality, the next column in the series will explore an example of it in action with Team Foundation Server 2010.

Let's Talk Theory
Figure 1 shows a basic representation of Branch by Quality.

[Click on image for larger view.]

Figure 1. Branch By Quality.

In the Branch by Quality model, there are three branches: Production, Quality Assurance (QA), and Development. The Development branch is where all major code development occurs. This is the branch developers will be checking their code into and out of during their daily development cycle. It is the most fluid branch of the three, and sees the most activity. The QA branch is used for testing the application and achieving final application approval. The QA branch is not as fluid as the Development branch, and should not see near as much check-in/check-out activity.

The Production branch contains the production code for the application. In Figure 1, imagine that the Production branch is made of brick, the QA branch is made of wood, and the Development branch is made of straw. Using this model, you always want to make the majority of your changes on the softest branch, in this case, the Development branch. As you move up the branch hierarchy, things get "harder," so few changes should be made on the QA branch, and changes should never be made directly on the Production branch.

The general methodology for this pattern is that development happens on the Development branch. When the application is ready for QA testing, the code is merged into the QA branch. At this point, the developers become hands off. They should not touch anything directly in the QA branch. Final testing is done in the QA branch. When the application has been tested and approved by QA, it is merged into the Production branch and released.

One variation to this pattern is to create Release branches off the Production branch (see Figure 2), and then make those release branches read-only. This creates a permanent branch of what went into production for that particular release, making it easy to find and recreate that particular release. At a minimum, this branch should contain the source code for that release, but also consider putting binaries, documentation, and any other objects related to the release in this branch.

[Click on image for larger view.]

Figure 2. Branch By Quality Variation.

For the final theory part of this branching pattern, we need to look at is how we might handle bug fixes. Figure 3 shows the workflow for how to handle a bug found on the QA branch during final testing.

[Click on image for larger view.]

Figure 3. Branch By Quality – Bug Fix.

Step 1 is the initial creation of our branch structure. In Step 1, we create our Production, QA, Development and Bug Fix branches. This establishes the branch relationships we need to perform merges at a later date.

In Step 2 we have finalized our development and are ready to move into final QA testing. We merge from the QA branch to the Development branch, to make sure we get any changes that have occurred, then merge from Development back to QA. At this point, the Development branch moves on to working on the next version, and testing begins on the QA branch.

In Step 3, a bug has been found in the QA branch. However, the bug can't be fixed in the QA branch directly, as no code changes are allowed directly on that branch. Instead, the bug needs to be fixed in the Bug Fix branch. First, the code from the QA branch is merged into the Bug Fix branch. The bug is resolved, and the bug fix is merged back into the QA Branch.

Finally, in Step 4 the code in the QA branch is ready to be moved into production. First, the Production branch is merged into the QA branch, to pick up any new changes (of which there shouldn't be any). Then the QA branch is merged into the Production branch.

However, you aren't done yet. For consistency sake, you should perform a merge from the QA branch to the Bug Fix branch, to make sure that branch has the latest code from QA. And finally, you need to perform a merge from the QA branch to the Development branch. The purpose of this merge is to take any bug fixes that were made to the code in QA, and apply those bug fixes to the Development branch code (since the bugs that were fixed are still in the Development branch).

As you can see, the Branch By Quality pattern is more powerful and flexible than the Branch By Release pattern discussed in previous columns, but that flexibility comes with the cost of added complexity. The reality is that if you are not careful, and don't have a documented branching strategy, this pattern can quickly spiral out of control. It is recommended that if you use this pattern, you have a dedicated person in charge of the branching and merging.

In our next column, we will look at how to implement this pattern using Team Foundation Server 2010, including a walkthrough of how to handle the bug fix scenario shown in Figure 3.