Contrary to popular belief, continuous integration is an attitude, not a tool. It's a shared agreement by the team that:

1. When we get the latest code from the repository, it will always build successfully and pass all tests.
2. We will check in our code every two to four hours.

There's lots of ways to make this happen, but they tend to be a variation on this theme:

1. Before check-in, run the build and tests and make sure they pass.
2. Tell people not to update from the repository because you're doing an integration.
3. Check in.
4. Go to a different machine (often a dedicated "integration machine"), get the latest code from the repository, and make sure latest changes build and pass there, too.
5. Done--tell people they can update again.

The purpose of step 4 is to make sure that the code will work on everybody's machine, not just the machine of the guy who wrote the code. You tell people not to update just in case it doesn't work. If it doesn't, you have to fix it or roll back your changes. Either way, people won't ever have a problem with getting code that doesn't work.

A while back, I ranted about Why I Don't Like CruiseControl. CruiseControl and its cousins are just a way of automating step 4.

If you use CruiseControl, be careful that you don't degenerate into this common and error-prone process:

1. Before check-in, run the local package's tests and make sure they pass.
2. Check in.
3. Done.
4. (CruiseControl runs full test suite over the next hour or so.)

This approach will lead to many more build problems and wasted time. First, you won't be running the full test suite before checking in, so the build will break more often. Second, you won't be "locking" the repository, so people will sometimes get code that doesn't work. Your test suite is likely to be slower, too, because you won't have to personally wait for the whole test suite to pass. This will allow you and your team to get away with sloppier, slower testing practices.

If you find yourself having a lot of build problems, consider going back to manual continuous integration. (I'm not suggesting manual builds; just not using a tool like CruiseControl.) It will be painful at first, but that pain will lead you to the source of your build problems, giving you an opportunity to fix them.