The 12 Steps of Continuous Integration
I recently gave a talk on Continuous Integration with Hudson. I’m planning on posting a number of how-to guides covering everything that I did, but to start with, here’s the core of the talk – The Twelve Steps
- Maintain a code repository
- Automate the build
- Make your build self-testing
- Everyone commits early & often
- Everyone expects their commits to succeed
- Every commit (to mainline) should be built
- Keep the build fast
- Test in a clone of the production environment
- Make it easy to get the latest deliverables
- Everyone can see the results of the latest build
- Keep the build “successful” – if you break the build, your first priority is fixing it
- Automate Deployment
Obviously, I’ve borrowed heavily from Martin Fowler, but as every recovering alcoholic knows, he’s two steps short. My additional steps are…
5. Everyone expects their commits to succeed
11. Keep the build “successful” – if you break the build, your first priority is fixing it
…and I also modified…
4. Everyone commits early & often
…which is probably of greater importance than both 5 and 11, even though it’s only half a line.
In his original, Martin says “Everyone commits every day” (but you already knew that, because you followed the link right?).
The problem is, I’ve worked with people who thought that “every day” meant “at the end of every day, regardless of the state of your code”. Sorry, but no. The whole point of CI is that you have an up-to-date, working system at all times. Once it becomes acceptable to check in broken code, then the whole thing falls apart.
Which also explains why I’ve added both 5 and 11 – whilst, in his prose, Martin extols the virtues of keeping the build working, none of his 10 points explicitly tell you to do that.
And who’s going to read the whole article when you’ve a list of bullet-points right at the beginning to scan through?