Version Control for Continuous Delivery Roots 2011 Stein Inge Morisbak
Version Control for Continuous Delivery
Nov 28, 2014
Continuous delivery depends on the ability to deliver reliable software releases through build, test and deployment automation. This is often easier said than done, as it depends on a lot of hard work building a robust infrastructure to support the flow from development to production. One of these crucial tasks is to design a reliable, flexible, easy-to-use and easy-to-comprehend strategy for version control.
I have experienced many times that teams are not able to put new features, or even bug-fixes, into production within a reasonable amount of time (i. e. less than a day). The reason is often that their code base is unstable because they don't have a reasonable branching-, merging- and release strategy.
I will in this talk present an easy and comprehendible version control strategy that allows team members to develop a shared understanding of the branching and releasing processes. Teams not practicing continuous delivery will also find this model useful to avoid "merging hell", unstable code bases and the like. In the examples I give I will use Git, but any version control system supporting branching and merging, like SVN or CVS, could be used to implement the strategy.
I have experienced many times that teams are not able to put new features, or even bug-fixes, into production within a reasonable amount of time (i. e. less than a day). The reason is often that their code base is unstable because they don't have a reasonable branching-, merging- and release strategy.
I will in this talk present an easy and comprehendible version control strategy that allows team members to develop a shared understanding of the branching and releasing processes. Teams not practicing continuous delivery will also find this model useful to avoid "merging hell", unstable code bases and the like. In the examples I give I will use Git, but any version control system supporting branching and merging, like SVN or CVS, could be used to implement the strategy.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Version Control for Continuous Delivery
Roots 2011
Stein Inge Morisbak
Our highest priority is to satisfy the customer
through early and continuous deliveryof valuable software.
How long would it take your organization to deploy a change that involves just one single line of code?
Do you do this on a repeatable reliable basis?
- Mary and Tom Poppendieck
Work in Progress (WiP)
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
Time
Develop
We have to separate WiP from production ready code
MasterInitial production version
Next production release
Next production release
F1 F2 F3
Release plan 1
F4 F5 F6
Release plan 2
F7 F8 F9
Release plan 3
F9Oh no!
Bug!
Fix Merge
Extra production release
F3
F2
Develop
We have to detach features from the release plans
MasterInitial production version
Next production release
Big bug!!
Time
F1Feature branches
F4
F5
F6
F7
F8
F9
F10
Next production release
Fix
F6
F7
F8
F9
F10
F4
F5
F3
F2
Develop
We have to detach hot-fixes from production and develop
MasterInitial production version
Next production release
Next production release
Big bug!! !
F1
!2
Big bug-fix
!1
Hot-fix branches
Extra production release
Extra production release
Extra production release
Feature branches
Develop
Code freezes, testing, preparation … - Release branches
F6
F7
F8
F9
F10
F4
F5
F3
F2
MasterInitial production version
F1
Next production release
Release 2
Next production release
Release 3
Next production release
Release 1 Release branches
!
Fix!
Hot-fix branches
Feature branches
Summary
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
WiP must be separated from code in production.
Hot-fixes must happen on code in production
Release branches prevent freezes and delays.
For more on version control, come to:
“Delivering Continuously” on Wednesday.
– Git cheat sheets.
– Feature branching vs. Continuous Integration.
– Avoiding BIG SCARY MERGES!
– Feature toggles.
– and a lot more …
BEKK CONSULTING ASSKUR 39, VIPPETANGEN. P.O. BOX 134 SENTRUM, 0102 OSLO, NORWAY.
WWW.BEKK.NO
Stein Inge MorisbakManager
+47 909 64 [email protected]
@steinim
http://open.bekk.no
Related Documents
