I know things have been a bit on the content-free side here lately, so I’m going to try and remedy that with some (you guessed it) content.
When I hear people talking about Continuous Integration (CI) lately one thing that seems to cause a fair amount of misunderstanding is that people talk about CI like it’s a product, not a process. On the day they set up their CI server (usually CruiseControl) the “have” CI. I would argue that exactly the opposite is true. CI is a process, not a product. More than that, it’s one of those nasty curves that I blocked out of my mind back when I didn’t do very well in Calculus. You can be forever approaching CI but you never quite get there. Huh? Well, if the goal of CI is to (you guessed it again) Integrate Continuously, we can’t ever quite get there because none of us would ever get any real work done.
So rather than “having” CI, we “do” CI, or better yet, we strive for it.
If that’s the case, what are we really striving for? We are striving to reduce the amount of time it takes us to do each (micro) integration, and maximize the amount of time that we as developers can spend adding business value to our software products by writing code. If we can’t add value because we’re busy integrating, we aren’t fulfilling are primary job function.
So: the closer we come to integrating continuously, the less time we should be spending on non-value-adding programming tasks.
Practically speaking, we can’t spend all of our time worrying about integration. We all have real work to do. What we can do is work on making the process smoother for everyone. That means not breaking the build. Let me back up a second… In order for everyone to be able to maximize their productive work, and maximize that of everyone else on the team, we need to able to commit changes without fear of breaking the build, or causing other people to have to do integration work needlessly. What that means in practice is that before committing any changes to our source code repository, we should get all the latest changes, run a full build and test cycle, and make sure we haven’t broken anything. If we have, we need to fix those problems, and go through the process again, getting source, running build and test, etc. until we get a clean cycle. If that process if followed by everyone on the team, then it should be very very difficult to break the build. The only way the build should break if everyone follows that process is if changes are being made to the tip of your source control system faster than the get/build/test cycle. Sometimes that really happens, and I’ll write some other time about how to deal with that.
So why do builds break? Because people don’t follow the processes. Why not? Usually for one of two reasons: 1) they don’t understand the process, or 2) the get/build/test cycle takes too long. #2 is the most likely cause, and happens much too frequently. In the initial literature on CI, Martin Fowler argued that any build/test cycle that takes longer than 10 minutes is likely to cause people not to follow the process. In practice, I’ve seen that to be the case as well. As soon as you get the cycle time down, people will start doing what they are supposed to be doing and the build will break less often.
If you currently have a build that takes too long, then reducing the build/test cycle time becomes part of your CI process. We’re always working toward the goal, remember. Make shaving a few seconds here and there off your build process part of the CI process goals. Every little bit improves your process, and will start paying dividends.