Team Foundation: Multiple release structure

Question

I am in need of help setting up a TFS branching structure.

The current scenario is as follows, our application is a SaaS, and I believe we need multiple "Release" branches simultaneously.

Going through the TFS Branching Guide III, I'm fairly certain that we will need the "Advanced" branching model.

We start with having a "main" branch, which will house the application as it stands right now (we're coming from Visual Source Safe). From that we will create a "Development" branch, and leave that alone for now. We will also create a new "Service Pack", "Hotfix", and "Release A" branch tree which will contain our current set of changes. We will then have our QA team analyze the "Release A" branch, and if it passes we will then close it (read only), and merge it back to "main".

That's all fine and dandy so far.

The problem arises, is that the QA cycle takes approximately a month, so in the meantime, we want our developers to work on new "Service Pack" and "Development" projects for "Release B", which will also have its own "Service Pack", "Hotfix", and "Release B" branches.

This means that we have 2 release branches going at a time (unless of course there's a smarter way of doing it).

Question: If "Release B" is created BEFORE a "Development" project is completed, then a "Hotfix" for "Release A" is required, how do I propagate that "Hotfix" from "Release A" into "Release B" without picking up any "Development" projects that get completed in the meantime?

Breannabreanne

Answer 1

Take a look at the graphic from http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/ And also read the entire blog entry:

Your "Development" projects are called "Sprint 1" and "Sprint 2" in the graphic...notice how the Sprints are isolated from Release--you can't get to them except via merge.

Curvet

I wouldn't describe our development environment as SCRUM, main difference being that we will not merge our changes from the Development branch (or "Sprint" in SCRUM's case) at the end of a cycle. Also how do you apply hotpatches from one release to another AFTER the 2nd release has already been created. – Breannabreanne

Using the diagram above, apply your hotpatch to the RTM branch. Then merge it up to the release branch. Merge again up to the main branch. Once it's in the main branch you can merge it two ways--to your Development branch (the "sprint n" branch above), or down to your next Release branch. – Curvet

RE:Comment#1: Replace word "Sprint" with "Version" or "Dev" or other term. The name "Sprint" implies a short release cadence but the diagram is valid for longer release cycles too. In Martin's diagram (above) I'd prefer RTM branches stay purely read-only (basically an immutable label of what was 'Released To Manufacturing (Web for SaaS)'). Make hotfixes in Release branch (which is your servicing branch in TFSBranchingGuideIII Standard plan). – Pelkey

Drat. Sent comment too soon. In Martin's diagram (above) I'd prefer RTM branches stay purely read-only (basically an immutable label of what was 'Released To Manufacturing (Web for SaaS)'). Make hotfixes in Release branch (which is your servicing branch in TFSBranchingGuideIII Standard plan). When hotfix is completed in Release1 branch it is merged through Main to "Dev2". If you need to safely get to "Release2" branch from Release1 without going through Main (because Main has other releases) then consider baseless merge (and plan very carefully to mitigate risk of merge conflicts!!!). – Pelkey

Answer 2

Question: If "Release B" is created BEFORE a "Development" project is completed, then a "Hotfix" for "Release A" is required, how do I propagate that "Hotfix" from "Release A" into "Release B" without picking up any "Development" projects that get completed in the meantime?

Short Answer: For the specific scenario described I believe you could safely merge From Release A through Main and then back up to Release B. (Yes, this is identical to what Geoffrey McGrath stated in a comment on 8/16.) Typically you don't do any FI merges from Main to a release branch after creating the branch, but if you can confirm the only change present in Main is your hotfix then the merge should safely accomplish your goal. HOWEVER this is based on the very questionable assumption that you have a clean Main branch with nothing else has merged into Main since "Release B Servicing" was branched. Verify this assumption very carefully before proceeding!

Dirty Main workarounds - cherry picking or baseless merge: If there are other changes in Main they you can cherry-pick merge the specific hotfix from Main to "Release B Service Pack". Another option is to do a baseless merge from "Release A Servicing" directly into "Release B Servicing" which bypasses any other changes in Main. (You still need to merge this fix through main so Dev branches get the hotfix.) Note that cherry-pick merges and baseless merges have higher risk than regular merges (which can be tricky enough as-is). Still they are valid options for specific scenarios where no better solution exists.

Meta-answer#1: I find drawing a diagram helps me follow the changes from original branch to the final destination. Cherry-pick doesn't have any special notation, but baseless merge can be arrow with dotted line. If it works on paper (and you accounted for all other branch interactions with Main) then it should work.

Meta-answer#2: If above hasn't outright answered your question then I'd recommend reading the http://tfsbranchingguideiii.codeplex.com/discussions forum and cross-post this specific request. Bill Hays is typically very responsive in that forum and your question definitely points to hotfix management within TFS branching.

---

FYI:

My team works on a few SOA (Service Oriented Architecture) projects which encounters similar challenges to SaaS. The one month QA cycle is a tough complication.

I like Martin's article a lot (enough to cite it again below). There are two additional articles worth reviewing (both have pretty pictures to augment nice TFS Branching Guide diagrams). However all three articles focus on dev branch management rather than hotfix release branch management (same as diagram in the earlier answer).

1. Guidance: A Branching Strategy for Scrum Teams - Martin Hinshelwood 2010.04.14 - Excellent walkthrough of basic "branch by release" strategy as a Scrum team works through 2 sprints (with great diagrams).
2. Branching for Scrum - Bill Heyes (ALM Ranger) 2011.01.18 - Excellent scrum team diagrams and scaling branches.
3. Parallel Feature Teams working on multiple releases in development. Monthly releases to production. - Bill Heyes 2011.01.14 - Very similar to our branching scenario (3 Web dev teams + 1 Prod env.). Guidance is Branch by Team + Branch by Release.

Enjoy! -Zephan

Pelkey