A key message the VSTS Rangers are trying to communicate in the VSTS Rangers Branching Guide 2.0 (http://tfsbranchingguideii.codeplex.com/) is that different companies have different needs and requirements for parallel development or release support (servicing). This is why we presented a progression of branching plans, starting with the basic plan, followed by the standard and advanced plan. Adopt the simplest plan that meets your company’s needs and requirements. Add complexity when it is justified. Each of the three branching plans in the guide builds on each other. They are not mutually exclusive. For a simpler application, particularly one that does not have significant servicing needs (such as hot fixes and service packs), the basic branching plan may suit your needs. When you find that you need a more complex approach, it is easy to add complexity in the future.
Before choosing a Branching and Merging strategy, make sure you (and your company) understand the concepts of Source Control Management (SCM).
The first step is to understand your company’s current software development and release workflow. Ask questions such as:
- How does the company release software?
- What are the company’s requirements for parallel development teams?
- Does the company need to support multiple releases in production?
- Does the company provide hot fixes or QFEs to resolve specific customer issues with released software? If so, what is the process?
- Does the company provide Service Packs for released software? If so, what is the process?
It is not uncommon for some companies to have complex processes to support their current workflow. As you evaluate this workflow, look for how the company does it today.
For example, assume a company makes heavy use of labeling to mark different versions of code in the same branch. When there is a high reliance on labeling, understand the problem the customer trying to address using labels. These problems typically map to the workflow which, you need to understand.