James Shore has been running a series of somewhat controversial posts about continuous integration.
The gist of his writings is that the benefit of continuous integration is realized by the discipline and approach of the team, not tools like CruiseControl (that silly "People over Tools and Processes" thing again. He really needs to go back for some CMM reeducation). He's also decrying the seeming reliance on CruiseControl as a crutch instead of a last chance safety net. I touched on the same subject a couple of weeks back on a post culled from the CI talks I have done this summer: Using Continuous Integration? Better do the "Check In Dance".
I agree with him, except about the usefulness and goodness of a tool like CruiseControl.Net. Even if your team is very disciplined about doing the "Check In Dance," it's still useful to have CruiseControl.Net around to do builds on a clean box. Like Shore says on his blog, people are always human. From time to time you're going to miss checking in a prerequisite code file or dependency assembly. Better source control clients like Ankh or TortoiseSVN for Subversion have cut that down to almost nil for us, but every so often it still happens. Those poor fools trying to do nontrivial development with VSS for their source control will suffer greatly from this (The WinCVS client for CVS is another common culprit).
Getting down into the muck of developing software systems, another very important raison d'etre for CC.NET is to catch environment setup needs. When we install Visual Studio.Net on a developer workstation the installation leaves all kinds of binaries scattered over your GAC, not to mention some lingering COM DLL's. These kind of dependencies might not be noticed when you're running the build locally, but will almost certainly blow up the clean CC.NET build. Using Crystal Reports comes to mind rather quickly. Another example that's bitten me plenty of times is making some sort of tweak to the local IIS web server to accomodate the code. Running locally? No problems. Running on CC.NET forces me to put the environment setup into the NAnt build script to keep everyone else from getting fouled up by the changed environment dependency. Bugs or just inefficiency due to environment mismatches is a huge pet peeve of mine.
Those are just some sample reasons to have a CI tool. Communication, records keeping, and statistics gathering are also aided by a CI tool. Take the "people" aspect of CI very seriously, but don't throw away CruiseControl.Net by any means.