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
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Source control branching and merging guidelines
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
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!
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