TFS 2010 branching model for an in-house application

Question

This is not a question where I don't have any ideas, but instead I would like to present a model and see if it gets approved or anyone can see issues with it or has better suggestions. They say it's better to carefully choose you branching model in order to avert future headaches.

So we have an in-house application with only one version (the latest) released to the customers and basically 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 is presented in the guide, the daily development would happen in the Development 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 Development 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?

Again I know it's not a simple, straightforward question but instead an open one, still I hope to hear from anybody with a similar experience. Thanks in advance for your attention.

Answer 1

Have you read the TFS ALM Rangers Branching Guidance documentation? What you are proposing looks pretty much like their "Standard Branch Plan", though they encourage having both a release and "service pack" branch (much like your Release and Maintenance branches above).

http://vsarbranchingguide.codeplex.com/

I've implemented the Standard Branching plan at a few clients and haven't had a problem with it. If you plan to adopt concurrent streams of work (feature crews, etc) the Branching Guidance has solid plans for that as well.

Another thing to consider might be a stair-step model where you create new Dev branches at each release and freeze the old one as a release. This would avoid RIs since you can just Hotfix the old one and FI the fix to the new Dev branch if necessary. I've worked in this model as well and it was awesome.