TFS branching model to support long QA (system testing) cycle

Question

Lets say you have an application. This application is to be QA tested and deployed to production. There are some constraints on the application lifecycle.

1. Only one version of the app will ever exist in production.
2. Once deployed to production if required hot-fixes may have to be developed. Hot-fix are narrowly targeted to fix specific high severity defect and not introduce new features. The hot-fix code change should be reverse integrated to other branches.
3. Before relessing to production for new feature release it must go through QA cycle.
4. After releasing to QA it takes significant time for testing the app. At the first QA cycle if QA opens 20 defects they need to be fixed in next release for QA without any more features to test. If QA team then reopens say 10 defects then on the next release to QA they only want those 10 defects to be fixed. No other defects or any new features. The next feature release can only happen after defect count is 0 (or some defects are decided to be not fixed or enhancement etc.).
5. Since the QA cycle takes time, during that time development cannot stop. New features should be continued to be developed for next feature release.

How would you setup your TFS branching model.

Answer 1

Sounds like you are a perfect candidate for the "Standard" strategy from the TFS branch / merge guidance: http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785

In essence this takes your basic Dev <-> Main <-> Release model, then adds one more layer of indirection. Hot fixes get their own branch on the Release side of the hierarchy, so that their development + testing doesn't disrupt the ordinary QA cycle happening in Main nor pollute the sanctity of Release. You can see a visual illustration on page 7 of the PDF.

Do you have an ironclad requirement that Release branch(es) represent an exact snapshot of production (i.e. there is a 1:1 relationship between checkins to Release and deployments, and/or a separate Release branch created per deployment)? If not then you may not even need the hotfix branch -- do hotfixes directly in Release. This is covered in the "Basic" strategy earlier in the document.

In any case, be sure to read the whole suite of documents. It's not long, but distills a lot of findings from real-world implementations. (the "VSTS Rangers" are primarily made up of MVPs and other on-site consultants)

For a longer, more theoretical look at team development strategies & their implementation in TFS, check out the papers from the Patterns & Practices group: http://msdn.microsoft.com/en-us/library/bb668991.aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title=html