Source control branching and merging guidelines

2,775
-1

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,775
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Source control branching and merging guidelines

  1. 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. 2. 14 September, 2010 Branching and Merging guidelines This devcafé Source control structure Branching and Merging Basic branch plan
  3. 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. 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. 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. 6. 14 September, 2010 Branching and Merging guidelines Demo
  7. 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. 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. 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. 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. 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. 12. 14 September, 2010 Branching and Merging guidelines Main branch Create When? When you create the project
  13. 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. 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. 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. 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. 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. 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. 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. 20. 14 September, 2010 Branching and Merging guidelines Links Guidelines on development wiki Visual Studio TFS Branching Guide 2010
  21. 21. 14 September, 2010 Branching and Merging guidelines Questions And answers!
  22. 22. www.orbitone.com Branching and Merging guidelines 14 September, 2010

×