Source control branching and merging guidelines

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

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

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

14 September, 2010
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 !?

14 September, 2010
New project structure
Client Name
Project Name
•Main
•Development
 Development branch 1
 Development branch 2
•Release
 Production

14 September, 2010
Demo

14 September, 2010
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

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

14 September, 2010
Basic Branch plan
Basic Branch plan
Stable main branch for testing
Release branch for bug fixes on live version
Development branches for development

14 September, 2010
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

14 September, 2010
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!

14 September, 2010
Main branch
Create When?
When you create the project

14 September, 2010
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 September, 2010
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

14 September, 2010
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

14 September, 2010
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

14 September, 2010
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

14 September, 2010
Challenges
Different solution names for different branches
Pro: more clear
Con: can’t merge all changes

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

14 September, 2010
Links
Guidelines on development wiki
Visual Studio TFS Branching Guide 2010

14 September, 2010
Questions
And answers!

www.orbitone.com
14 September, 2010

Source control branching and merging guidelines

Recommended

More Related Content

Viewers also liked (20)

Similar to Source control branching and merging guidelines (20)

More from Orbit One - We create coherence (20)

Recently uploaded (20)

Source control branching and merging guidelines