My continuous integration articles have caused more comment than anything else I've written. Obviously, this is an emotional point for a lot of people. I'm not sure why--maybe someone will enlighten me. (If you can refrain from calling me a bozo while doing it, all the better.) I don't have comments enabled on my blog, for various reasons, but you can always contact me through email at the address listed at the bottom of this page.

My two previous articles on this subject are:

1. Why I Don't Like CruiseControl
2. Continuous Integration is an Attitude, Not a Tool

Brad Clarke sent me an email that covers a common point: we need continuous integration because people make mistakes. Although he called me a bozo (in so many words, in the subject line), he makes some good points.

The 10 minute build + test is just as good with an automated build server as without. By focusing on that as the reason for having the build server is really missing the point. Software is developed by people and people make mistakes. If something is automated then the number if mistakes is more likely to decline than increase. By using a tool such as CruiseControl to automate steps 4 and 5 of your list the probability of human error has been reduced and software quality will go up.

OTOH, if you set up your build environment correctly you should never really feel the need to go build on another computer to call your code "integrated" as your tests would have found the problem the first time. Only the numbskull type of errors are going to cause those sort of problems (forgot to "cvs add" most of the time) so why should you be chasing after numbskulls all day long when that process can be automated and easily fixed when found?

In general, I agree with Brad--particularly his second paragraph. I would love to see a build environment where I can be confident that, if the tests pass on my computer, they'll pass everywhere.

In my experience, though, that's not always true. It's not just forgotting to "cvs add," although that is common. There are more subtle issues, such as changing a local property file or registry setting, or installing some software, and not putting it in the overall build. Because of these issues, I think there will always be a need to run the build and tests on a different computer.

If a team is using CruiseControl (and cousins) just to automate step 4 and 5, then more power to them. The problems I see are twofold:

1. I often see teams using CruiseControl that don't have the shared agreement and feeling of responsibility for "we will never check in code that won't build" that underlies true continuous integration. Instead, one or two people feel that way and are using CruiseControl to force the "bozos" to step into line. You can imagine how well this works.

   If you're on an agile team and using a tool to solve a people problem, you're missing the point. "People and interactions over processes and tools," as the agile manifesto says. Get everybody to agree to take responsibility for the build, then install CruiseControl.

2. A second problem I see is teams using CruiseControl to catch their mistakes, not act as a rarely-needed safety net. This is a real and common problem--the team lets their build times get out of control, they stop running all of the tests themselves, and of course they start running into escalating build problems.

In general, I would rather see a team embrace the philosophy of continuous integration, get to know what it's like without a tool like CruiseControl, and only install CruiseControl after they truly understand continuous integration.

What I tend to see instead is people saying, "We want continuous integration, so we'll install CruiseControl." Those teams run into problems 1 and 2 pretty quickly. I suppose they're better off than they were before, but "automated builds" is not nearly as fun or powerful as "we know the code in our repository always works." With these articles, I'm trying to help these people realize there's another step.