This project has moved and is read-only. For the latest updates, please go here.

TFS 2010 Branching Strategy

Jan 11, 2012 at 10:01 PM

We have an in-house application with only one version (the latest) released to the customers and basicaly there are 2 kind of development activities; the main activity is working for the next release and usually includes new features and corrective fixes and it is planned, and the second one which is not planned and is about maintenance and includes hotfixes of the current version in production.

After long research we decided to go with a Main trunk from which we branch-out 2 child branches: Development & Maintenance(or Hotfix). As it ise presented in the guide, the daily development would happen in the Develpment branch from where we do reverse integration (RI) everytime we have features ready for the next release. Right before the release the reverse integration will stop and the code will be stabilized in the Main branch. After the release from Main there will be a forward integration (FI) from Main to Development and Maintenance.
Any hotfix will happen in Maintenance only and depending on the fix (for example if we want to retain it in the codebase) we will do a RI into Main and from there a FI into Development

Now everything looks all right, at least on paper, so I would like to hear others' opinions on this model.

For example we would also considering having another branch, Release, where the stabilizing of the code happens before a release to production (instead of working directly in Main) and of course we will release from here to production and do a RI into Main followed by a FI to Development & Maintenance, but we're not sure if this will bring any benefit or will just increase the complexity?

And assuming that there will be features in Develpment that won't be ready or not desired for the next release this means we will have to do some "cherry picking" of the changesets that are related to the wanted features, but that's not too good according to the docs. Any suggestions?

Thanks in advance for your attention.

Jan 11, 2012 at 10:35 PM

I don't understand why you need to cherry pick development features to put in main.  Is your development team focussed on completing the first release and delivering it before starting the next one?  If so, then all their features that are complete and tested should go. Even code for an incomplete feature can go into production as long as it is tested to be harmless and invisible. A release is usually a big event. Everyone knows it is coming. I am not likely to start a totally radical change to the UI in the last sprint before the release.

If the problem is that some developers start working on the next version while the current one under development is beng finished, then there are several branching options to isolate that from the branch being prepared for release. 

Jan 12, 2012 at 5:03 PM

First thanks for your answer.

Well things in real life are not that straight and clear as on paper. I saw cases when a feature was retired right before the release, sometimes they realized it's not really what they wanted or what end-users wanted or even politics and stuff. Now this may happen because of bad practices in some other parts of the whole development process (like requirements management) so until we fix everything we have to deal with all sort of "unnatural" things. I have a few of concerns now and I feel uneasy about other issues that might show up and we might not be able to handle them because of a poor decision about branching strategy. For example I am afraid some features will go all the way to UAT and then won't pass and we will probably need to roll-back changesets in Main branch because the release date cannot be pushed further because of other 10 urgent features. Probably a better solution would be to inactivate the undesired features using some sort of configuration flags.
I don't know, I would like to start as simple as possible but not simpler and adding while we go ahead.

So looking at the scenario I presented what do you suggest about the branching model we should adopt. Someone else on another forum told me that a Standard Branch Plan (TFS Branching Guide - Scenarios 2010_20100330.pdf) would work fine in our case. But I could not find a Scenario Overview for this Standard Branch Plan in the TFS_Branching_Guide_Scenarios_2010_v1.pdf as only {Single Team}, {Concurent Hotfix, Service Pack and v.Next} and {Branching with Labels} are covered. I would like to see Standard Branch Plan explained in terms of how to manage the next release and hotfixes, when to do FI & RI, , where to stabilize the code before a production release, what branch get released to what environment, some Q&A etc.


Jan 13, 2012 at 4:11 AM

I have a variety of suggestions. I hope that some of them will be useful.

First, I recommend that you carefully study the TFS_Branching_Guide_Scenarios_2010_v1.pdf, and in particular the first two scenarios (development and hotfix etc...) Although they may not look exactly like the standard branch plan, they provide additional explanation for the most common scenarios used in all of the branch plans. In other words, think of the branching guide scenarios as a shared and reusable reference that provides additional clarity for all of the branch plans. For example, the first scenario,"Scenario #1: Single Team Branching Model ", can provide insight regardless of whether you chose the basic, standard, advanced, or mature branch plans as described in "TFS_Branching_Guide_Main_2010_v1.pdf." That scenario teaches you some of the mechanics of how to handle development activities. Likewise, the second scenario, describes a variety of hot fix and release related activity.

You have successfully understood several of the ideas found in the branching guidance. But I sense that you need to play with it a little bit and get more comfortable with how the concepts translate into the mechanics. I strongly recommend that you set up a sandbox team project working project collection, put a copy of your solution in it, and experiment with the branching plan of your choice. Then you can test some of YOUR scenarios, and then document for yourself the preferred rules for forward and reverse integration. This lack of experience is one of the greatest impediments for people who are just getting started with branching. But of course, if you don't have experience, how do you get started? The answer is that you play - you experiment. Once somebody suggests it, it seems really simple. But many people forget to create a sandbox and play. They think that they have to pick the perfect branch plan and put it into production immediately even though they don't have any experience with branching plans. Of course you're anxious if you're contemplating that approach. Your anxiety will go away if you do some experiments. One of the things that will happen if you do experiments is that you will train yourself how to do branching properly and you will reduce the chance that you will make mistakes. The other thing you'll discover is that it is very unlikely that you will back yourself into a corner and create a mess if you pick one of the branch plans recommended by the ALM Rangers in the branching guidance.


That is how I learned to understand the branching guidance. I read it several times and I got some of the ideas, but it just didn't fully fit together until I played with the branching tools and walked through various scenarios. The beauty of the sandbox is that you can try out a large number of widely varying scenarios without any risk or discomfort. So you can conduct a large number of experiments in a very quick amount of time.

When I work with teams that need a branch plan, I take the PowerPoint slide deck provided in the branching guidance package. It is named TFS Branching Guide - Diagrams 2010_20100330.pptx. Then I use the graphics to create my own branch plan and I create my own scenarios, complete with written rules. For example, you could have a scenario that describes what people are supposed to do when they start development, and a different scenario for what to do when the software is ready to release. You could provide a different scenario that describes branching merges or rollbacks that were needed if somebody comes up with a feature that gets all the way to user acceptance testing and has to be removed.

On a slightly different topic, you may also be hampered by a misconception that the selection and design of a branching plan is a simple algorithmic task. It is not. Designing your own branching plan is a lot more of a heuristic activity. My point here is that you will not find a written instruction that tells you step-by-step what to do to fit your situation perfectly. Instead, you will have to design your own branching plan, modeled after existing ones, and adapted using the rules of guidance. What you do is start with one of the plans listed in the guidance. The standard branch plan seems like a perfectly good place for you to start. Then you study the scenarios and you play with them in your sandbox. But you play with them in a very scientific way. You take each of those scenarios that you describe in your earlier post, and you perform a simulation to see how you would handle it. For example, you wrote of a scenario where

"some features will go all the way to UAT and then won't pass and we will probably need to roll-back changesets in Main branch because the release date cannot be pushed further because of other 10 urgent features"

If you are really concerned about that scenario, test it out in your sandbox. If you can figure out how to use branching to solve your problem, it will reassure you that the branch plan you have tested will work for you in this situation.

What you may find it is that trying to use branching to solve a problem with the broken development process is not the best solution. It would be better to figure out how a feature gets all the way to user acceptance testing and instead of fixing it, you decide to deferr it to a future release. That sounds really bad to me. The problems with that feature should have been found and fixed much sooner in the process when there was plenty of time to get it done correctly. To be more precise, the testers should have been collaborating with the developers much earlier in the development process. Or, what is the point in having a user acceptance testing activity if you are not going to allow for time to repair the defects? I know this happens far too often. But it is ridiculous. I mean, you have to keep in mind, that if you rollback a change set, you may affect shared code that breaks other things and you will have to rerun all the regression tests in every other area. So rolling back the change set may be more dangerous than leaving the broken feature in the build in planning and emergency hot fix soon after the release. If you are going to ignore problems with personnel and process like this, and hope to use branching to mitigate the problem, I fear you are going to be disappointed with the final result.  But I want to reiterate that the ideal agile approach would be to make sure that features that reach user acceptance testing should rarely have showstopping defects that cannot be repaired in a timely manner.

I apologize if it seems that I was getting hung up on that one example that you gave. But it illustrated a really good point that I have seen arise in this discussion forum again and again. In some cases, people try to design the branching plan to mitigate problems that should really be solved in some other way. Since we are talking about heuristics, the rule would read something like this

"If you have an unusual problem situation and you think you need a special branch to fix it, before you design and implement that branch, consider other ways you could solve that problem without using branching. Then choose the solution that makes the most sense."

In one situation you may find that branching techniques are the answer. In another situation, you may prefer that design you proposed that involves configuration switches which can turn the unapproved features off. And finally, there may be situations in which somebody needs to change the people are policies to prevent a recurrence of this unfortunate situation.

Jan 13, 2012 at 3:28 PM

Hmmm, nicely put. That was helpful thanks. Prabably what I needed was a kick in the... but it was worth :-)

Feb 18, 2012 at 10:43 PM

I may have read something on this forum a while back that could help see link below...