The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.
Here’s what I think:
- Goals: rapid feedback, fail fast, always releasable, simple (i.e., easy to use)
- Visibility is important here, too: Everyone can see what’s happening
Mainline and CI
- There should be a mainline – Everyone Commits To the Mainline Every Day
- IMO, the mainline – i.e., what you are working on every day – should be ready to release from at almost any time. This implies low technical debt, and little difference between mainline and a release branch (if you use that) – i.e., less work in progress at any time.
- Maybe a release branch is a good idea – where you actually can release from at any time
Branches and merging
- Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
- Branches: Merge from mainline every day if you have them.
- Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
- Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges
-
Illustration from Henrik's article Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.
Inspiration:
Martin Fowler: articles on continuous integration
Henrik Kniberg: Agile version control with multiple teams