Branching in TFS 2010: Part III (End-User Pattern)

In Part II of this article, I discussed the Third Party branching pattern and how to create it in TFS 2010. In this part, I'll be talking about the End-User pattern. Whereas the Third Party pattern was a variation of the Branch by Release pattern, the End-User pattern is a hybrid between Branch by Feature and Branch by Quality.


End-User Projects

What we call End-User Projects are typically web applications. This means that only a single version is ever in production at a time, and each of these goes through customer UAT before being deployed into production. Therefore, we needed the ability to promote the code through various quality stages. But given the complexity of some of the applications, we also wanted to incorporate feature branching. This was accomplished using the following model (click on the image for a larger view):


This pattern consists of 5 primary branches:

1. Production - this is the top of the hierarchy, as all branches are child branches or below of this one. The code in here represents "production ready" code which is ready to be deployed. Typically code in the Production branch is released immediately after merging into this branch.
2. Test - the Test branch represents release testing, meaning code testing prior to its release. This is to be distinguished from testing bug fixes to code that is already in production.
3. Development - this is the main branch, and where almost all development occurs. It contains the latest code with the most up-to-date feature set.
4. Bug Fix Test - this branch is used for testing bug fix releases. Normal deployments from Development to Production will never pass through this branch.
5. Bug Fix - the Bug Fix branch is the development branch for coding bug fixes. This has to be distinctly different from the Development branch because new code in the Development branch shouldn't be merged into production along with a bug fix. Without this branch (and Bug Fix Test), there would need to be a code freeze while fixing bugs, and that's a cardinal no-no in the world of branching.

In addition to the above five branches, there are individual feature branches off the Development branch. There is also an individual read-only branch for each release, which are branched off the Production branch.

In order to create this pattern in TFS, we first create the folder structure. The structure is similar to what was in Part II, with the addition of a Features folder. It should look like this when completed:

Once the basic folder structure is created, it's time to create the branches. 

1. First, convert the Production folder to a branch.
2. Branch the Production branch into a Test branch and place it in the root folder.
3. Branch Test into a Development branch and place it in the root folder.
4. Branch Production into a Bug Fix Test branch and place it in the root folder.
5. Branch Bug Fix Test into a Bug Fix branch and place it in the root folder.

When you're done, it should look like this:

The branch hierarchy should look as follows (you can view this by right-clicking on the Production branch, going to "Branching and Merging" and choosing "View Hierarchy"):

Finally, check in your project code into the "source" folder of the Development branch. This can simply be an empty project at this point.

Now that the basic branch structure is all set up, I'll go through a typical development process including feature development, testing, deployment, and bug fixes. Let's start with the development cycle, which is entirely contained to the Development branch and its child Feature branches:

To create these branches:

1. Branch Development into a "Feature 1" branch, located in the "Features" folder.
2. Branch Development into a "Feature 2" branch, also in the "Features" folder.

It should look as follows:

Initially, this pattern will keep feature development independent. I say "initially" because it won't stay that way for the entire life of the project. This isn't necessarily a big deal, but it is important to be aware of it. While each feature is being developed, neither is "aware" of the other. After Feature 1 is merged into the Development branch, upon completion, then it becomes part of the mainline code. As soon Development is merged into the Feature 2 branch just prior to unit testing Feature 2, the Feature 2 branch will contain Feature 1. After this point there is no easy way to go back to a purely-Feature 2 branch. Normally this is okay and not a problem. If for some reason you need to revert, you can rollback the changeset from the merge operation.

Once all of the features have been completed, unit tested, and merged into the Development branch, it's time for a deployment.

As you can see, the first step is to promote the code from Development to Test by merging the Development branch into the Test branch (and checking in the Test code afterward). After that, integration testing is performed on the code in the Test branch. Once that is done, merge code down from Production to Test, to make sure any potential conflicts are resolved. You might want to do additional testing at this point, too. After that, merge the code in the Test branch into Production (and check in). Finally, create a read-only branch from Production for the release. The process for doing this is the same as in Part II.

Now let's say after Release 1.0 has been deployed, we discover a bug in production that needs to be fixed right away and can't wait until the 2.0 release. No problem!

Here are the steps for creating an incremental bug fix release:

1. Merge code from Production to Bug Fix Test.
2. Check in Bug Fix Test code.
3. Merge code from Bug Fix Test to Bug Fix.
4. Check in Bug Fix code.
5. Code the bug fix in the Bug Fix branch.
6. Merge code from Bug Fix Test to Bug Fix prior to unit testing (in case any other bug fixes were going on at the same time).
7. Unit test the bug fix code in Bug Fix.
8. Merge code from Bug Fix to Bug Fix Test.
9. Check in Bug Fix Test code.
10. Merge code from Production to Bug Fix Test (in case any other bug fixes were deployed while this one was being worked on).
11. Perform integration testing of the bug fix code in Bug Fix Text.
12. Merge code from Bug Fix Test to Production.
13. Check in Production code.
14. Create a read-only branch from Production for the incremental release.
15. Now we need to merge the bug fix into our mainline code. Merge the Production code into the Test branch.
16. Check in Test code.
17. Finally, merge the code from Test down into Development.
18. And, of course, don't forget to check in the Development code.

That completes an overview of all the major tasks involved with End-User projects. In the next part, I'll cover the Internal project pattern.

Here's a slideshow that covers the information in this article:

Branching in TFS 2010 Part III (End-User Pattern)

View more presentations from jvaran