I only recently discovered CruiseControl. In my years of Java work, I used Ant extensively, but never came across a system like CruiseControl that did builds continually through out the day.
CruiseControl enforces Continuous Integration, which is the concept that developers should be integrating their code with the larger system at least once a day. Usually, integration is done infrequently and is a painful exercise. If integration becomes a part of a programmer’s daily ritual, it becomes less painful as the developer is integrating smaller chunks of code.
In its simplest form, CruiseControl executes a NAnt script on a regular schedule. That schedule could be when ever code is checked in, or every hour during the day. If the NAnt script fails, the build manager is notified with an e-mail. CruiseControl also includes a web-based dashboard that displays the current status of the build and gives the user the ability to force a build.
It’s been my experience that these interim builds don’t go anywhere. But, they find many errors long before a deployment to a server. Generally, these errors are akin to not including a new file in source control, or changing a file locally without checking it out. In other words, the errors that keep the build manager up late the night before a milestone is supposed to go out to the development server. It also doesn’t allow developers to check in code that doesn’t compile (a cardinal sin on any project).
Coninuous Integration is a relatively new concept, but one that is generally understood and embraced. Another concept that CruiseControl can enforce is controlled deploys. I’ve been on too many projects where deployment requires an entire document of instructions or worse, there is no documentation and a specific individual with special knowledge has to do the deploy. Usually, these sorts of builds have many steps that include such things as “after copying all files to the server, open a telnet session and type the following arcane commands”.
If CruiseControl is used for deploys, then the only interaction can be a button click (the force build button in the CruiseControl dashboard). The NAnt script has to handle all the steps for deployments. Since only discrete steps can be included the NAnt script, the fuzzy logic associated with a deploy falls away.
Having to use NAnt for deployments doesn’t limit the scope of what can be done, but it does force the build manager to really think about their deployments and be very specific about each step. NAnt has the ability to do everything from copying files to executing arbitrary .NET code. In that spectrum of functionality the build manager should be able to codify the deployment.
This is a better situation for several reasons. First, the deploy process can be put into source control along with every other piece of code in the system. This allows the process to be versioned, reviewed and tightly controlled, just like any piece of code.
Since the build is now kicked off by a single button click, any one can do a deploy to the server. The build manager being sick, on vacation or generally inaccessible doesn’t preclude the possibility of a deploy. This becomes key when those show stopping errors are found and a new build needs to be pushed out immediately.
In general, the process of deploying a system to the server is one of those “details” that is overlooked until the tail end of the project. The build and deploy process should be as rigorously tested as any component of the system. Using the combination of CruiseControl and NAnt, allows for controlling deploys as tightly as builds.