Chapter 27: Automating Continuous Integration with CruiseControl

Overview

In this chapter we introduce you to CruiseControl and show you how to use this tool to assist with continuous integration. CruiseControl is an automated build tool that leverages your Ant build scripts and your version control systems to ensure that your projects are continually integrated. CruiseControl is written in Java, and so has the same cross-platform benefits that tools such as Ant and JUnit provide.

Where to Get CruiseControl

CruiseControl was originally developed by Thoughtworks Inc. to assist its developers on a large development project. It was then released as open source in early 2000 and developed a large following. CruiseControl is distributed under a BSD-style license and can be downloaded at http://cruisecontrol. sourceforge .net/download.html.

At the time of this writing, the current version of CruiseControl is 2.1.5.

CruiseControl comes in a "source-only" distribution; you will have to run the build scripts provided before using it.

 

CruiseControl is based on a simple concept. A CruiseControl instance is normally set up to watch a version control repository, and to detect changes to the files in the repository. When changes are detected , the instance will update a local copy of a project from the repository, and then invoke the build script for the project. After the build is complete (either successfully or unsuccessfully), the CruiseControl instance will publish various user -specified artifacts (including the log of the build), and inform the project members of the success or failure of the build.

This tool offers a lot of flexibility in how it achieves these tasks . A number of types of version control repositories are supported, including CVS, Subversion, ClearCase, and Visual SourceSafe. These repositories can be monitored at regular intervals or at preset times. Although CruiseControl was built to use Ant build scripts, it also comes with support for Maven, another Java-based build tool. Results can be published to a Web site, or sent out via e-mail, or copied to another machine. Finally, CruiseControl comes with a fully functional sample Web application that you can use to view the build logs.

Like Ant, CruiseControl was designed to be extended. All of the components it uses are built around a plug-in architecture (inspired by a similar mechanism in Ant), and writing your own plug-in to support your own environment is easy. Several of the components in the CruiseControl distribution have been contributed to the project by members of the community.

CruiseControl supports a team practicing continuous integration by ensuring that builds are performed on a regular basis as your project evolves. This is similar to the concept of the nightly build that many companies (such as Microsoft) practice but occurs even more often. CruiseControl supports continuous integration by ensuring that the builds are performed, even when we fallible humans forget. In addition, the tool can make it feasible to reduce the amount of effort required by developers for their local builds; developers can, for example, run only tests relevant to the work they were doing, and rely on the CruiseControl server to detect if a change has broken an unrelated area. Finally, CruiseControl can be used to run tests and tools that would not normally be run by developers.

CruiseControl is only as effective as your build script, however. To leverage CruiseControl, you must have an effective build script. On the plus side, having a good build script has lots of other benefits, as discussed elsewhere in this book.

What Do Your Build Scripts Do?

Developing effective build scripts is very much a learning experience. Build scripts will vary between projects, sometimes quite dramatically, based on the needs of each project.

As a rule of thumb, however, your build scripts should do a minimum of two things. They should "build" the project, and they should "verify" the result of the build. Building the project involves compiling source code, packaging it up into a distributable file, and completing the various other steps involved in getting from input to output. Verifying the result includes such activities as running code analyzers (like Checkstyle and PMD), unit tests, and integration tests.

The "holy grail" of automated builds is a result you can use with confidence and as few steps as possible. For a J2EE application, this would be an EAR file and possibly configuration scripts for targeted application servers. For a client-side application, this would be a set of files ready to burn to a CD and install.

How close do your build scripts get to this?

 

There are alternatives to CruiseControl, naturally. A number of places have "rolled their own" build systems, based on their own build scripts. The UNIX cron command works well for scheduling builds, as does the Windows at command. Another example of a continuous build system based on Ant is AntHill.

In the next section, we describe how to configure CruiseControl for an existing project.