Team Foundation: Multiple release structure

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 hou开发者_C百科se 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?

---

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.

---

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