SCM Guidance

 

Much of our guidance was adopted from the Microsoft Team Foundation Server Branching Guidance published by John Jacob, Mario Rodriguez and Graham Barry. We are in a communication loop with the authors to provide feedback and refinement as we test our scenarios.

We have provided folder structure along with a number of visio diagrams on this page, which will serve as guidelines for how to handle some of the Branch and Merge conditions that you may encounter. A whitepaper is forthcoming.

Some of the scenarios have folder diagrams with accompanying line diagrams. You can see that branch and merge scenarios are much easier to envision if you think in terms of line diagrams. Try to create line diagrams of your scenarios first, and then branch or merge off of your respective folders.

 

Project / Folder Organization

Project folders in TFS should be organized in the following manner with the following naming conventions:

– Project Name

  • Development
    • Version Number
      • Database
        • Solution Name
      • UI
        • Solution Name
  • Main
    • Database
      • Solution Name
    • UI
      • Solution Name
  • Production
    • Database
      • Solution Name
    • UI
      • Solution Name

Branch per Release Model

Branch Per Release Model

Branch per release model combines 2 isolation models, integration isolation and release isolation, into a single branching structure. The root branch or Main is the integration branch. Main is a staging area for integrating and stabilizing work from other branches, and as such no active development takes place in Main.

Note: The term “release” does not have to refer to a new version of the product; it may refer to releasing to a test team from a dedicated branch so issues can be fixed independently from development continuing on the development branch.

Timeline:

A. V1 Dev is created from Main

B. V1 Release

i. Release is created from Main

ii. V2 Dev is created from Main

C. V2 Dev integrated with Main

D. Release Label

i. Fixes are integrated from Release to Main

ii. V2 Dev integrates from Main

E. Service Pack

i. Service pack is integrated from Release to Main

ii. V2 Dev integrates from Main

F. V2 Release …………….

The process cycles through in this manner with separate releases Labeled according to their milestones. It takes time to move changes between branches. A Typical merge operation involves stabilizing the source branch, executing merge, conflict resolution then stabilization of the target branch. On large projects, scenarios taking days, weeks or even months are not uncommon.

 

Multiple Release Model

Multiple Release Model

The multiple release model combines 3 isolation models, Integration isolation, Release isolation and Team Isolation models into a single branching structure. This is designed for large teams working on multiple releases of a single application. The root branch or MAIN is the integration branch. Like the Branch per Release model above, Main is a staging area for integrating and stabilizing work from other branches, and as such no active development takes place in Main.

Timeline:

A. Team (Dev) branches are created from Main

B. Integration Milestone

Team 1 integrates with Main

C. Integration Milestone

Teams 1, 2 and 3 integrate with Main

D. Team 1 Release

Release is created from Main

E. Release Label

Fixes are integrated from Release to Main

Team 2 and 3 Integrate with Main

F. Service Pack

Service pack is integrated from Release to Main

Team 2 and 3 Integrate with Main

G. Team 2 Release

Release is created from Main

H. Release Label

Fixes are integrated from Release to Main

Team 3 Integrates with Main

B. Team 3 Release

Release is created from Main

 

Hot Fix Scenario: Parallel releases will be handled as hot fixes since they are essentially always hot fixes from production releases. Hot fixes must be reverse-integrated all the way to Main by the team completing the hot fix.

 

Folder diagram for Multiple Release / Hot Fix Scenario .

 

 

 

Advertisements

 
%d bloggers like this: