Team Foundation: multiple release structure

Question

I need help creating a TFS branching structure.

The current scenario is as follows: our application is SaaS, and I believe that we need several "Release" branches at the same time.

Having walked through the TFS III Branch Guide, I’m sure we will need an extended branching model.

We start with the presence of the “main” branch in which the application will be placed, since it stands right now (we come from Visual Source Safe). From this we will create a branch "Development" and leave it alone. We will also create a new Service Pack, Hotfix, and Release A tree that will contain our current set of changes. Then the QA team will analyze the “Release A” branch, and if it passes, we will close it (read-only) and merge it back into “main”.

It's all fine and dandy still.

There is a problem: the QA cycle takes about a month, so we want our developers to work on the new "Service Pack" and "Development" projects for "Release B", which will also have their own packages "Service Pack", "Hotfix" and "Release B".

This means that we have two release branches going at a time (unless, of course, there is a more reasonable way to do this).

Question: If “Release B” is created before the “Development” project is completed, then a “Fix” for “Release A” is required, how can I extend this “fix” from “Release A” to “Release B” without raising any Development projects that end in the meantime?

Answer 1

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

Your Development projects are called Sprint 1 and Sprint 2 in the chart ... note how Sprints are isolated from Release - you cannot get to them except by merging.

Answer 2

Question: If “Release B” is created before the “Development” project is completed, then a “fix” for “Release A” is required, how can I distribute this “fix” from “Release A” to “Release B” without raising any projects "Development" to be completed at that time?

Short answer:. In this particular scenario, I believe that you can safely merge with Release A on Main, and then return to release B. (Yes, this is identical to what Jeffrey McGrath said in comment 8/16.) Usually you do not merge FIs from Main to the release branch after the branch is created, but if you can confirm that the only change present in Main is your fix, then the merge should safely accomplish your goal. HOWEVER . This is based on the very dubious assumption that you have a clean Main branch, and nothing else merged with Main, as "Release B Serviceicing" was forked. Check this assumption carefully before proceeding!

Dirty main workarounds - cherry picking or unreasonable merging: If there are other changes in the "General" section, you can use the cherry merge to install a special fix from "Main" in the "Release B Service Pack". Another option is to make an unreasonable merger with "Release A Servicing" directly in the "Release B Service", which bypasses any other changes in Main. (You still need to merge this patch using the main one, so Dev branches will get the patch.) Note that cherry merges and baseless merges have a higher risk than regular merges (which can be quite complicated as-is). However, they are feasible options for specific scenarios where there is no better solution.

Meta-answer # 1: I find that drawing a chart helps me track changes from the source branch to the final destination. Cherry-pick has no special notation, but baseless merging can be an arrow with a dashed line. If it works on paper (and you took into account all other interactions with the branch with Main), then it should work.

Meta-answer # 2: If there was no answer directly to your question above, I would recommend reading http://tfsbranchingguideiii.codeplex.com/discussions and cross-post this specific request. Bill Hays is generally very responsive in this forum, and your question definitely points to patch management in TFS branches.

---

FYI:

My team is working on several SOA (Service Oriented Architecture) projects that are facing similar issues for SaaS. The round QA cycle is a complex complication.

I like Martin's article (enough to cite it again below). There are two additional articles worth considering (both have beautiful images to enlarge the diagrams of the TFS branch diagram). However, all three articles focus on dev branch management, and not on patch branch management (as in the previous answer).

• Manual: Scrum branching strategy for teams - Martin Hinshelwood 04/04/14 - An excellent step-by-step guide to the basic “split-to-release” strategy of how the Scrum team works through 2 sprints (with large diagrams).
• Branching for Scrum - Bill Hayes (ALM Ranger) 01/01/18 - Excellent command diagrams for splicing and scaling branches.
• Parallel functional groups working on multiple versions in development . Monthly issues to release. - Bill Heyes 01/01/14 - Very similar to our branching script (3 teams Web dev + 1 Prod env.). Leadership is a team unit + branch version.

Enjoy it! -Zephan