>Martin Fowler’s “Continous Integration” article should be required reading. Particularly if you are working with a global team of developers in disparate locations. It defines a set of patterns and rules for helping to keep builds clean and working.
What I find more interesting besides patterns, are Anti-Patterns. Those things that people do that just don’t work. In particular, I’ve found a couple of articles of late that discuss Anti-Patterns when it comes to continuous integration.
- Automation for the people:Continuous Integration anti-patterns – by Paul Duvall
- Continuous Integration anti-patterns, Part 2
- Avoiding Build Breakage Patterns In Continuous Integration
These three articles cover the most common reasons why an integration build will commonly fail. I’m sure most of those who follow the process of continuous integration have fallen into one of more of these anti-patterns at some point. It is important though that once we fall into them we recognize it and try to work our way out of them. Keeping a build clean especially with a dispersed project team is critical to knowing that the system is working, and that unforseen changes haven’t crept in. It is especially important when there are inter-related dependencies.
If a build fails for any reason, it should be given higher priority over what ever you are working on. A failing build means there is something wrong. As Paul Duval says:
…builds become increasingly more troublesome to fix the longer they stay broken. This is because there are more files, more changes, and more dependencies that make the isolation of the defect difficult.
Keep your builds clean and it will make your development process that much easier. If you are using Cruise Control to run your builds, then check out the 3rdPartyCCStuff for ways to monitor the builds.