Why I Don't Like CruiseControl
April 8, 2005
I have a confession to make: I don't like using CruiseControl.
CruiseControl is an open source tool from ThoughtWorks. When you check in source code, it automatically checks it out, runs your tests, and tells if anything went wrong. Some people even hook it up to green and red lava lamps to indicate whether the build is working or not. It's very cool.
Why do this? Because XP projects, and many agile projects, have a rule that looks like this:
Source code in the repository must always build and pass our tests.
This is a wonderful rule. I firmly believe that every project, agile or not, will be more successful if it can incorporate this rule into its process.
So CruiseControl helps you enforce this rule, and it does it in an effective and even sexy way. Sounds like a great tool, right? Actually, it is. Many people consider it a standard part of their agile toolkit and lots of projects use it.
Not me.
CruiseControl is a traffic cop: it doesn't help you follow the rules; it just tells you when you've broken them. If the team does their job, and never breaks the build, you'll never hear from CruiseControl. So why use it? I've seen two common reasons:
- The build does fail--often enough for CruiseControl to be valuable.
- The automated build process is too slow to wait around for.
Both of these reasons are actually opportunities to improve. The first one is easy: if your build is failing a lot, you have a clear opportunity to improve.
The second case--slow builds--seems like a good reason on the surface. Digging deeper, I often find that the build is slow because the tests are slow. Digging deeper still, I find that the tests are working too hard, often doing too much database work. Rise to the challenge of fixing this and you'll find that your tests are easier to maintain and your code better designed.
Bottom line? If you're using CruiseControl, it's a clear sign that you have opportunities to improve. Try to get to the point where, like me, you don't like CruiseControl... because you don't need it.
Hoo, boy, do I expect to be flamed for this one! Okay, before you unpack those flamethrowers, let me clarify one thing: I do think CruiseControl is valuable in some situations. The biggest one? When the team is transitioning to agile development and has a large legacy process or source code burden. In those cases, the build fails a lot, and CruiseControl is a valuable cleanup tool. That doesn't change what I said, though: the team has an opportunity to improve. But you already knew that.
The other case where I see that CruiseControl is valuable is in certain kinds of heavy-duty testing. Monte-carlo simulations, some kinds of performance testing, memory leak testing, some kinds of automated regression testing. These are all legit, and can be very slow. But "the build is slow" excuse is overused. With good unit tests and good customer tests (using a tool like Fit that doesn't require your customer tests to be end-to-end tests), you simply won't need that many slow tests. Ask yourself if you have lots of slow tests because you don't have enough fast tests. Slow tests are more costly to maintain than fast tests (and not just because they're slow), so again, there's an opportunity here.
Okay, you can go ahead and unburden that flamethrower now.