Introduction to the Basic Branch plan as proposed by Microsoft. At Orbit One we use this to have a structured yet user friendly source control and deployment process

1. www.orbitone.com
Orbit One BVBA
Raas van Gaverestraat 83
B-9000 GENT, BELGIUM
Website www.orbitone.com
E-mail info@orbitone.com
Tel. +32 9 330 15 00
VAT BE 456.457.353
Bank 442-7059001-50 (KBC)
Presenter: Mel Gerats
14 September, 2010
Branching and Merging guidelines

2. 14 September, 2010
Branching and Merging guidelines
This devcafé
Source control structure
Branching and Merging
Basic branch plan

3. 14 September, 2010
Branching and Merging guidelines
Current project structure in source control
Client
Trunk
•Project 1
•Project 2
•Project 3
Branches
•Project 1 release 1
•Project 2 release 1
•Project 2 release 2
(Most of the time)

4. 14 September, 2010
Branching and Merging guidelines
Problems
Messy structure
What branch is the live version?
Who works on which branch?
I need to deploy, now what?
I just fixed a bug but cannot deploy it !?

5. 14 September, 2010
Branching and Merging guidelines
New project structure
Client Name
Project Name
•Main
•Development
 Development branch 1
 Development branch 2
•Release
 Production

6. 14 September, 2010
Branching and Merging guidelines
Demo

7. 14 September, 2010
Branching and Merging guidelines
What does it solve?
Better structured
One release branch if there is only one release
Always have a stable, feature complete, staging environment
Always have a deployable version
Allow concurrent development

8. 14 September, 2010
Branching and Merging guidelines
How do we solve this?
Basic branch plan
Developed by the Visual Studio ALM Rangers
On codeplex
http://tfsbranchingguideiii.codeplex.com/

9. 14 September, 2010
Branching and Merging guidelines
Basic Branch plan
Basic Branch plan
Stable main branch for testing
Release branch for bug fixes on live version
Development branches for development

10. 14 September, 2010
Branching and Merging guidelines
Terminology
 Main branch
Stable main branch used for QA. => Staging
 Release branch
Corresponds with live version. Used for hotfixes
 Development branches
Branches for planned changes
 Forward integrate
Merge changes to a child branch
•Main -> Development
•Main -> Release
 Reverse integrate
Merge changes to a parent branch
•Dev -> Main
•Release -> Main

11. 14 September, 2010
Branching and Merging guidelines
Requirements
Single major release
Your servicing model is to have customers upgrade to the next
major release.
Any fixes shipped from the release branch will include all
previous fixes from that branch.
Omg that sounds like a website!

12. 14 September, 2010
Branching and Merging guidelines
Main branch
Create When?
When you create the project

13. 14 September, 2010
Branching and Merging guidelines
Development branches
Create when?
You need to develop something new.
Forward Integrate when?
Forward Integrate with each successful build of Main
Main changed? -> merge changes into Development branch
Reverse Integrate when?
Reverse Integrate (RI) based on some objective team criteria (e.g.
internal quality gates, end of sprint, etc
Feature is done -> merge into Main
ONLY COMPLETE FEATURES

14. 14 September, 2010
Branching and Merging guidelines
Release branch
Create when?
When you deploy to production
Reverse Integrate when?
Every time the Release branch is changed
•Bug fix
•Content update?
Release branch changes -> merge it into Main
Forward integrate when?
Each release
Merge into Release branch -> deploy

15. 14 September, 2010
Branching and Merging guidelines
Project lifetime
 New client, new project
Create new Team Project
Create Project Folder
Create project in Main branch
Create development branch
Start developing
 Feature is done
RI into Main, deploy to staging
 Features are approved
Create release branch
Deploy

16. 14 September, 2010
Branching and Merging guidelines
Project Lifetime
 Two new features! Two developers
Create new development branch for one
Start developing on different branches
 Feature One Complete
 Forward integrate Main into dev
 Reverse Integrate into Main, deploy to staging
 Forward Integrate into Dev 2
 Feature Two complete
 Forward Integrate Main into Dev 2
 Reverse Integrate Dev 2 into Main, deploy to staging
 Forward Integrate Main into dev 1
 Features approved
 Reverse Integrate changes from Release into Main
 Forward Integrate changes from Main into Release
 Deploy release
 Drink beer

17. 14 September, 2010
Branching and Merging guidelines
Challenges
How to handle specific feature releases
Feature 1 can go live, Feature 2 can not
2 options
Specific development branch for some changes
•Vnext
•Vnext +1
OR
Merge a specific change set, not the latest version

18. 14 September, 2010
Branching and Merging guidelines
Challenges
Different solution names for different branches
Pro: more clear
Con: can’t merge all changes

19. 14 September, 2010
Branching and Merging guidelines
Tips
Forward Integrate often
As often as possible
Communicate!
If there are multiple developers, make it clear what work is done
where

20. 14 September, 2010
Branching and Merging guidelines
Links
Guidelines on development wiki
Visual Studio TFS Branching Guide 2010

21. 14 September, 2010
Branching and Merging guidelines
Questions
And answers!

22. www.orbitone.com
Branching and Merging guidelines
14 September, 2010