Waltzing with Branches [ACCU]
•Download as PPT, PDF•
0 likes•456 views
The use of branches within a version control system is a risk management technique. They are commonly used to minimise the risk of unanticipated side-effects when releasing critical changes to production, or to minimise the disruption to developer productivity when making changes to the base product. But branching is not the only means of managing risk and that is what this talk addresses – the forces that drives the use of branches, what are their problems and what are the alternatives.
![Cargo Cult SoftwareCargo Cult Software
EngineeringEngineering
““They go through the motions of looking likeThey go through the motions of looking like
effective organizations that are stylisticallyeffective organizations that are stylistically
similar. But without any real understandingsimilar. But without any real understanding
of why the practices work […]”of why the practices work […]”
---- Steve McConnellSteve McConnell](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
Viewers also liked
Similar to Waltzing with Branches [ACCU]
Similar to Waltzing with Branches [ACCU] (19)
More from Chris Oldwood
More from Chris Oldwood (14)
Recently uploaded
Recently uploaded (20)
Waltzing with Branches [ACCU]
- 1. Waltzing with BranchesWaltzing with Branches Chris OldwoodChris Oldwood ACCU Conference 2016ACCU Conference 2016 @chrisoldwood | gort@cix.co.uk@chrisoldwood | gort@cix.co.uk
- 2. Cargo Cult SoftwareCargo Cult Software EngineeringEngineering ““They go through the motions of looking likeThey go through the motions of looking like effective organizations that are stylisticallyeffective organizations that are stylistically similar. But without any real understandingsimilar. But without any real understanding of why the practices work […]”of why the practices work […]” ---- Steve McConnellSteve McConnell
- 3. Another cult is born…Another cult is born… https://twitter.com/jezhumble/status/400071665482088448
- 4. Read the small print!Read the small print! https://twitter.com/jezhumble/status/400071665482088448
- 5. Waltzing with BearsWaltzing with Bears
- 6. <<<<<<<<<<<<<<<<<<<<<<<< Knox in box.Knox in box. Fox in socks.Fox in socks. Knox on foxKnox on fox in socks in box.in socks in box. ======================== Socks on KnoxSocks on Knox and Knox in box.and Knox in box. Fox in socksFox in socks on box on Knox.on box on Knox. >>>>>>>>>>>>>>>>>>>>>>>>
- 7. “RISK MANAGEMENT IS PROJECT MANAGEMENT FOR ADULTS”
- 8. ““The business of believing only what you haveThe business of believing only what you have the right to believe is calledthe right to believe is called riskrisk managementmanagement.”.” ---- Waltzing with BearsWaltzing with Bears
- 9. ““Risk management is the process of thinkingRisk management is the process of thinking out corrective actions before a problemout corrective actions before a problem occurs, while it’s still an abstraction.”occurs, while it’s still an abstraction.” ---- Waltzing with BearsWaltzing with Bears
- 10. Risk: Loss of ProductivityRisk: Loss of Productivity https://commons.wikimedia.org/wiki/File:Mengniu-production-line.jpg
- 11. Risk: Loss of ConfidenceRisk: Loss of Confidence http://melvillegroup.com/wp-content/uploads/2013/08/fear-man-biting-nails.jpg
- 12. Risk Management StrategiesRisk Management Strategies Avoid itAvoid it Contain itContain it Mitigate itMitigate it Evade itEvade it
- 16. Release BranchRelease Branch 3 4 5 6 7 A B Stable Volatile
- 17. Branching From a LabelBranching From a Label 3 4 5 6 7 A B v1 X Y v1.1
- 18. Cherry PickingCherry Picking 3 4 5 6 7 A CB
- 19. Feature/Task/Private BranchFeature/Task/Private Branch 3 4 5 6 7 A B C More Stable More Volatile
- 20. ShelvingShelving 1 2 4 5 6 3
- 21. Integration PainsIntegration Pains 3 4 5 6 7 X Y Z A B
- 22. No BranchNo Branch 1a 2 1b 3 1c
- 23. Gatekeeper WorkflowsGatekeeper Workflows 3 4 5 6 7 X Y B Alice Bob C GK Z D
- 25. Branching is a technique forBranching is a technique for managing risk, but…managing risk, but…
- 26. Branching isBranching is not the onlynot the only technique for managing risk.technique for managing risk.
- 27. ApproachApproach Always Be Ready ToAlways Be Ready To ShipShip
- 28. Small Units of ChangeSmall Units of Change https://upload.wikimedia.org/wikipedia/.../1280px-A_Sunday_on_La_Grande_Jatte,_Georges_Seurat,_1884.png
- 29. AutomationAutomation http://trendingchannel.com/wp-content/uploads/2013/01/China-car-production.jpg
- 30. Continuous Integration is aContinuous Integration is a mindset, not a tool.mindset, not a tool.
- 35. Literature (Old & New)Literature (Old & New)
- 36. BranchingBranching cancan be used tobe used to managemanage somesome risks, but thererisks, but there are more productive ways.are more productive ways.
- 38. Blog:Blog: http://chrisoldwood.blogspot.comhttp://chrisoldwood.blogspot.com @chrisoldwood | gort@cix.co.uk@chrisoldwood | gort@cix.co.uk Articles:Articles: http://www.chrisoldwood.com/articles.htmhttp://www.chrisoldwood.com/articles.htm
Editor's Notes
- Brief bio – gave a related talk a few years ago, but coming from a different angle now. It’s an emotive subject – not helped by the tools giving us more power to avoid the real issues (it’s always a people problem).
- http://www.stevemcconnell.com/ieeesoftware/eic10.htm Coined the phrase in early ~2000 (term much older – most famously the Melanesian islanders just after World War II). Teams aspire to be like the cool companies – adopt the right practice and it will come. Branching is one practice that appears to be acquiring cargo cult status.
- https://twitter.com/jezhumble/status/400071665482088448 It’s easy to see how it happens – who wouldn’t want this? If a huge company like Google can make it work – we must be able to!
- The last entry in the list is fundamental to making the rest work. Also, Google have the funds and people to create the tooling they need to make it work.
- The talk’s title comes from a famous book by DeMarco and Lister. It’s name comes from a song by Dr Seuss - My Uncle Terwilliger Waltzes With Bears.
- - Dr Seuss’ writing often seems like the result of a botched merge .
- The book is about managing risk on software projects, but has wider appeal as risk management is more useful than that. It’s less than 200 pages long. Initial story about William Kingdon Clifford’s paper The Ethics of Belief.
- Whilst philosophical in nature it actually learns towards the scientific method for justification. Links back to the cargo cult mentality.
- Risk management versus crisis management (i.e. risk has materialized). Anyone who has worked in software development for a while should be able to come up with a list pretty quickly.
- Breaking the build for everyone. Checking in without even compiling and then going on holiday for two weeks! Loss of productivity down the pipeline – testers, deployment, etc. Leave broken or fix it and move on?
- Does the change we made work without breaking something else? Do we even trust the person making the changes?
- Risk as a pejorative misses the opportunities. Turn a risk into an opportunity to learn instead – experiments, Chaos Monkey, etc.
- Branching is attractive as it’s cheap on time and resources (due to immutable data structures). Only really 2 branches from a collaboration perspective – integration and private (sharing or working alone).
- Should call it Merging Strategies. Merge debt – analogous to Technical Debt (changes accrued but not integrated). Pain is at the end, often when time pressures are most upon us. General wisdom (if you’re going to merge regularly) – only merge from stable to volatile.
- - The default branch when VCS doesn’t support branching. Called different names - trunk/main/master. Explain representation – time is left-to-right. - A common “Enterprise” anti-pattern for big teams is one integration branch per project.
- - Reaction to code freeze – branch to avoid holding up development of version N+1. - Ideally trunk still needs to be stable prior to branching – no last minute high-risk changes that might be pulled. - Need integration branch when starting from a label. Very few, carefully reviewed changes expected - only essential changes. Organisation or regulatory requirements may require them to be used for quarentine purposes.
- Special case of a release branch (patch or hotfix) when supporting multiple product versions. Potentially time-critical, e.g. security fix. Label is snapshot in time whereas a branch is evolution.
- - Undesirable, but often a reaction to an overly long testing phase. - Small, focused commits make it easier to cherry pick as changes are isolated. - Heavy refactoring makes this much harder as the likelihood for dependent changes increases. - Changes can get lost on the merge back at the end. - Record a merge at the end as nothing has changed code-wise but the loop should be closed.
- - Polar opposite of release branch. - Branch for a specific feature (task) – often volatile in nature, e.g. a spike. - Or the developer may be volatile, e.g. new joiner. - Not necessary a single-developer branch, can allow multiple people to work more freely. - Easy to throw away with no residual effects (e.g. Spike).
- - Very short-lived branch, effectively only one commit. - Put current changes to one side and integrate again later when dust has settled. Supported natively by some, called “stashing” in Git, branch from working copy is an alternative in SVN. Was more useful when the working copy was large and disk space was scare.
- - The release merge is easier due to small focused changes. The feature branch merge can be harder because of the potential volume for change, e.g. refactoring. Not just syntactic merge conflicts, but semantic conflicts which cause upheaval as they’re often more subtle.
- - Back to the old days when branching wasn’t possible . - Break task down into much, much smaller tasks. - New code and refactorings don’t require toggling off, only changes (low risk, but not no risk). - Need to schedule clean-up after toggled on permanently. - Toggles can be compile-time (#ifdef) or runtime (.config entries).
- - Pessimistic workflow that uses feature branches and (ideally) automation to manage the risk. - Gatekeeper can be manual (code review) or automated (merge + build + tests).
- Forks are another type of branch, may be very short-lived or never merged. Look into iojs and node branch split and merge.
- Fundamental change in mindset away from big releases and siloed development to incremental change. Before knowing what agile development was this concept was what drove my change in behaviour. Be careful of what you perceive as waste – it may enable a reduction in opportunity and technical risk. Unlike some ad-hoc development it’s carefully orchestrated – requires discipline.
- Deliver software in smaller chunks (Allan Kelly’s Diseconomies of scale). Many of the processes we historically put in place are to minimise the problems from big changes, but are self-reinforcing, e.g. CAB. Opportunity risk comes from delaying changes, e.g. the scheduler refactoring.
- - Large amounts of automation are needed on any non-trivial codebase to help assure quality. Commit should trigger the continuous integration server to watch your back. - Optimistic workflow assumes commits are correct and should be ready to ship. - The only breakage should be environmental or long-running tests that can be elided by developers. - Build number should be auto-generated and baked into artefacts where possible. - Wipe workspace if you can afford it, else clean thoroughly to give same effect – no uncommitted hacks should taint the build.
- Having a CI server does not necessarily mean you are doing continuous integration. CI is about close collaboration to minimise waste, not establishing a blame culture when the codebase deteriorates. Implies smaller units of change.
- - The testing pyramid (programmer versus customer). **Tweet about test types.** Must be fast and easy to run (i.e. automated).
- Point out amount of code that changes at Google (on Jez’s tweet). Instead of trying to get it right first time, work with what we know and refactor as our understanding grows. - Physical structure changes are hard with long lived branches, less so with VCS’s that do (implied) directory versioning.
- Two heads really are better than one. Helps eliminate waste caused by building the wrong thing. And keeps quality up as it aids building the thing right.
- - Close monitoring allows opportunity to be exploited sooner because there is still a tight feedback loop when in production.
- - SCM Patterns book – it may be old but it’s got the principles.
- - In summary: branches have their uses but managing risk by avoidance should not be top of the list.
- - No books, just a blog and some articles – one on branching strategies in particular.