Single Team Branching Model

Jun 1, 2010 at 6:22 PM

In the PDF diagram "TFS Branching Guide - Scenarios 2010_20100330.pdf", what is the purpose/meaning of the "Single Team Branching Model".   Is that a simplification of the "Basic Branch Plan"? Or is it just sort of an enlargement/zoom on just two branches of the "Basic Branch Plan"?


I don't see how the plans on the right side of the diagram relate to the three (Basic, Standard, Advanced) plans on the left side of the diagram.


Thanks,

Neal

Developer
Jun 8, 2010 at 5:07 PM

When we developed the branching guide, we organized guidance into separate documents. The Main document contains our basic guidance and best practice recommendations.

The scenarios document was *intended* to buid upon the Main guidance by describing specific scenarios with guidance for how one might create a branching structure for that scenario.

Rather than suggest the the Single Team Branching model is a simplification of the Basic Branch Plan, I would prefer to say that it focuses on a particular aspect of the Basic Branch Plan. Since this scenario focuses on how to support a single development team (as opposed to multiple feature teams, for example) - the scenario focuses only on the Main and Development branches. In fact each of the branching plans in the Main Document (basic, standard, advanced) have the same structure on the development side of the branch tree.

I often like to separate the discussion of *How should I structure my Development branches* from *How should I structure my Release branches*. There are times, however, when how you relase software may directly impact your development brances, for instance where you are developing a product for multiple customers, and you need to have development branches to isolate customer-specific customizations, and perhaps release branches that isolate releases for specific customers. But often, the structure of the development teams can be a completely separate discussion from the requrements for supporting multiple releases, or hot fixes, or service packs.

For this reason, the scenarios tend (or may tend) to focus on one side of the the branching structure (for example Development) and not the other side (for example Release).

Other branching guides I have read tended to offer confusing and complicated scenarios which were arbitrarily combined into one *choice*. For example (Single Team, Single Release vs. Multiple Feature Team, Multiple Release). By being (or attempting to be) more granular in the scenarios, hopefully you will be able to mix and match different scenarios together to form a complete branching strategy.

Regards,
Bill Heys
VS ALM Ranger