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?
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.