At our yearly 1 week Zühlke web camp a couple of us took the opportunity to share experiences with branching and release techniques.
- Focus on Continuous Integration
- Every change that you have locally is a branch (a code version that is different than main)
- Every kind of branching delays Continuous Integration
- Only a healthy code base with a “green” Build + Automated Tests let you sleep like a baby at night.
Things to think about:
- How can you slice your work so that you can commit every 1 hour? (Incremental change)
- How can you get faster feedback from your Build Server?
- How can you do code reviews and keep quality high?
- Why do you need the 1 person code gate keeper that signs off all code?
This is what we found:
2 overall goals
- Get features to the user as fast as possible.
- Ensure our work is good (quality aka the “the thing right”) and good for the user (“the right thing”)
What is Continuous Integration?
“Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.”
If you have shelve-sets (TFS), stashes (git), long lived (>1day) feature branches you are not doing Continuous Integration. You are delaying the Integration work which is waste and a potential risk. Even if you have a sophisticated build system that builds all branches and each distinct tree in a revision list, you still don’t know if all integrates well.
Why Continuous Integration?
Are all our changes healthy? Is our main line healthy? Could we release the code on main line just now to Production? Why not?
We want get fast feedback about our code base.
In an agile context we are very keen on feedback and implement lots of feedback loops. One of those feedback loops is the Build Server feedback as illustrated on Use Continuous Delivery to build the right thing.
What techniques for branching exist?
Note: Every change that you make on your local machine is in fact already a branch. That change needs to be merged (commit&push, check-in in TFS terms) back to main
- Release Branch: A code version that is released to an environment has its own branch.
Do you create this branch on release time? Or later if you need a bug fix for that environment?
I prefer the latter since you create unneeded complexity in your code base (waste).
- “Spike” Branch: A code version that you potentially throw away or just want to share with another smaller group of developers.
- Feature Branch: A code version where your work on a feature is isolated from others.
Some more are documented here https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
What does it depend upon which technique you use?
- Team size
- Available Tooling + Team Skill level
- Release procedure
- Software Architecture (Web, SmartClient, MobileApp)
What are reasons that you don’t have 1 main branch?
Other interesting branching and releasing models
Branch by Abstraction
“anything in the master branch is always deployable”
Other interesting techniques
- „Feature Toggling” http://martinfowler.com/bliki/FeatureToggle.html
- “Canary Releases” http://martinfowler.com/bliki/CanaryRelease.html
- "Dark Launching" https://www.facebook.com/note.php?note_id=96390263919
In my experience “Feature Toggles” can lead to similar problems as lots of branches:
- What is on and off on this environment / server?
- Does Feature X work in conjunction with Y?
But some advantages I found:
- Testing gets easier
- Either something is stable (no toggle) or not (toggle)
- No build needed for special patches
- Feature not working OK in Production? Turn it off
How many FeatureToggles do you have in your system?
Do you remove them consistently once they are “done”?