Version Control for Continuous Delivery
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.
Recommended
More Related Content
Viewers also liked
Viewers also liked (19)
More from Stein Inge Morisbak
More from Stein Inge Morisbak (12)
Recently uploaded
Recently uploaded (20)
Version Control for Continuous Delivery
- 1. Version Control for Continuous Delivery Roots 2011 Stein Inge Morisbak
- 2. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 3. 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
- 4. Work in Progress (WiP) F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 Time
- 5. We have to separate WiP from production ready code Extra production release Master Initial production version Next production release Next production release Bug! Merge Fix Develop F1 F2 F3 F4 F5 F6 F7 F8 F9 F9 Oh no! Release plan 1 Release plan 2 Release plan 3
- 6. We have to detach features from the release plans Time Master Initial production version Next production release Next production release Big bug! ! Fix Develop F1 F4 F8 Feature branches F2 F5 F7 F10 F3 F6 F9
- 7. We have to detach hot-fixes from production and develop Extra production release Extra production release Extra production release Master Initial production version Next production release Next production release Big bug! ! ! Big bug-fix Hot-fix branches !2 !1 Develop F8 F4 F1 Feature branches F7 F10 F5 F2 F6 F9 F3
- 8. Code freezes, testing, preparation … - Release branches Master Initial production version Next production release Next production release Next production release ! Fix! Hot-fix branches Release 2 Release 3 Release 1 Release branches Develop F8 F4 F1 Feature branches F7 F10 F5 F2 F6 F9 F3
- 9. 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 …
- 10. Stein Inge Morisbak Manager +47 909 64 372 stein.inge.morisbak@BEKK.no @steinim http://open.bekk.no
Editor's Notes
- Hello my name is Stein Inge Morisbak and I want to talk to you about version control for continuous delivery.How many of you are doing agile development?How many of you are doing continuous delivery?
- The first principle of the Agile Manifesto is actually about continuous delivery.It actually states that it’s are our highest priority.So it’s not a new thought.But it hasn’t had that much focus until recently.
- And it’s not just important because of the ability to deliver valuable software fast. Although that is nice.It is also about quality and reliability. It is about practicing and practicing until you have a deployment process that doesn’t fail.It’s about deploying fewer features at a time and hence taking less risk every time you deploy to production.It’s about having a well defined process that everyone understands and are able to perform on a reliable basis at any time.It’s about automation.It’s about safety.
- Code bases under development are never done done! Unless you schedule everything to be finished on a certain date, have code freezes and so on.But that’s not very agile, is it?So, the code base is never production ready! There’sallways unfinished features.When to release? There is no single point in time in this code base where everything is done done at the same time.
- What happens if you forget to merge the bug fix into development?What happens if features are delayed?
- Grey arrows: Potentially shippable
- Rember to merge back to develop!
- Release branches frees up the development branch for further development.It also frees up the master branch for bugfixes.