Software for Continuous Integration - Cruise Control & Hudson Compared


Cruise Control is a well-established continuous integration (CI) server and is doing a good job. So why would we even consider using something else – and all the upheaval of changing? The author was fortunate to operate the two systems side-by-side for a while for a busy development team. This review presents a comparison with Hudson and will attempt to provide some answers.

The table below does not promise to provide a complete list of all features; in particular, there are many other plugins not listed here.  However, we try to indicate using smileys for features where a one system has an advantage over the other.


Cruise Control


Source code

Pure Java open source

Pure Java open source


BSD-style licence

MIT licence (with Creative Commons licenced artwork)



Sun via

Approx. inception v2.0 Feb 2002 v1.0 Aug 2005
Current version at time of writing v2.8.1 Nov 2008 v1.306 May 2009


Straightforward: unpack a zip of files and run the startup script.

Trivial: a single executable jarfile is provided.

Can also run in a servlet container.


Releases are infrequent but require manual upgrade.

Minor releases are frequent but easy to accommodate just by replacing a single file and then restarting the server. Automated upgrade can be launched from the web UI.

Service setup

Needs some scripting in /etc/init.d or similar

Needs some scripting in /etc/init.d or similar

Container technology

Comes with Jetty.

Comes with Winstone. Can also run on another standard servlet container such as Jetty or Tomcat5.


Good - but prone to certain types of build failure, e.g. deadlocks have caused problems.

Very good.

Controlled shutdown

Not available.

Allows for controlled shutdown, completing all current builds.

Means of configuration

Hand-written XML; this can be fragile and has caused server failures on occasions.

Via web UI; information is recorded in easily-inspected XML files.

Plugin configuration

Some hand-editing of source files is needed.

All configuration is via the web UI.

Dashboard security

None; all users can alter the small range of editable parameters but most configuration is done through XML.

User authentication is via HTTP Basic mechanism. Credentials are checked against a local table or a configurable LDAP service or via the servlet container.


Projects are organised in simple flat structure in which each project is independent of all the others.

Since v2.7 it has been possible to put common configuration settings in a shared ‘base’ config file.

Projects can be independent, and can also be organised in hierarchies such that completion of one build triggers the dependencies to build also.

It is not possible to share configuration settings between projects but it is easy to create new projects using the facility to clone existing ones.


Not available.

Related projects can be grouped into views – these make it easier to manage a large number of projects.

Access to log information

Once a build has completed, only XML information is available and it can be difficult therefore to diagnose build problems. There is no access to the Subversion polling history.

Build logfiles are always available. Subversion polling history is also available, useful to diagnose any build-schedule issues.

Subversion support

Yes but only for change detection (checkout/update is via Ant instead)

Yes: supports change detection, checkout and/or update.

Other SCMs supported Accurev, Alien Brain, ClearCase, CVS, Darcs, Git, Harvest, Mercurial, MKS, Perforce, PVCS, SNapshotCM, StarTeam, Synergy, Surround, MS Team Foundation, VisualWorks Store, MS VSS Accurev, Bazaar, Bitkeeper, ClearCase, CVS, Git, Mercurial, Perforce, PVCS, StarTeam, Synergy, MS Team Foundation, MS VSS

JDK support

A single JDK is used for all projects. Separate installations must be created if multiple JDKs are to be used.

More than one JDK can be specified. Each project can specify which JDK to use.

Ant support

Yes (but see log output remarks above). Only one version can be used per installation.

Yes. Each project can specify which Ant version to use.

Maven2 support



Email notification



Jabber notification

Yes – via a plugin.

Yes – via a plugin.

RSS notification



Multiple executors

Yes – see notes below

Yes – see notes below

Distributed builds


Yes – see notes below.

JUnit output analysis


Yes – via a plugin which produces useful trend graphs.

Emma output analysis


Yes – via a plugin which produces useful trend graphs.

FindBugs output analysis No Yes – via a plugin which produces useful trend graphs.

Checkstyle output analysis

Yes – via a plugin (configuration requires manual editing of source code)

Yes – via a plugin which produces useful trend graphs.

Disk usage analysis


Yes – via a plugin which produces useful trend graphs.

Bugzilla integration

Yes – via plugin

Yes – via plugin

Initiating builds

Builds can be started manually via the web UI.

Builds can be started manually via the web UI, and also by scripting.

Dependent projects start automatically after their antecedents have built successfully (or, optionally, always).

Aborting builds

Cannot abort a build once started.

Builds can be aborted from the web UI.

Build history management

There are no tools to manage old builds. Deletion or archival of old builds has to be done manually using the Linux command line. Otherwise the server eventually runs out of space, at which point everything fails horribly.

Individual builds can be either deleted if unwanted, or marked as permanent if needing keeping. Otherwise builds accumulate until configurable thresholds are reached, beyond which the oldest builds are purged automatically. Over several months, this saves a very significant amount of disk space.


Not much is available, but what is there is good.

Much more extensive documentation.

Overall impression

Mature stable product that is starting to show its age.

Youthful capable product, which has now given some years of good service.

Large Number of Projects

Many software systems are built from a collection of Eclipse projects, each comprising a module within the overall system.  Sometimes, when branches are used, this can result in large numbers of project variants, each requiring its own build if the Continuous Integration principle is to be followed fully.  It would be possible to reduce the number of build jobs on the CI server by only having one for each of the branches.  However, experience shows it is often better to have one build job for each branch of each Eclipse project.  Even though there may be a large number therefore, Hudson handles this well.  Comparing CruiseControl with Hudson, the latter has a clear advantage in this case, being simpler and quicker to administer.

Given a potentially larger number of build jobs, the ‘view’ feature of Hudson is, unsurprisingly, very useful.  Related jobs are shown on one view page - this might for example be used to show all the modules of one particular branch.

Multiple JDKs

If more than one Java version is to be supported, CruiseControl is awkward: it is necessary to set up more than one server instance, one for each JDK. Hudson handles multiple JDKs within a single instance: another clear win for Hudson.

Multiple Executors and Distributed Builds

Both systems allow the number of executors to be configured. For example, when set to four, up to four builds can proceed concurrently.  This is a considerable benefit on a multi-core server, although there is a risk of poorly isolated unit-tests etc interfering with each other.

In addition, Hudson can operate in master/slave mode, where a single master installation provides the web portal and can optionally delegate builds to one or more slave servers. The web UI hides the actual master/slave operation from users so that only administrators need be concerned about the parallelisation. The main benefit is that increased build throughput can be obtained.  Another clear win for Hudson.


Hudson offers a range of advantages which bring benefit to the business. Its configuration via web UI is less likely to introduce errors and considerably easier to diagnose problems. Its user security will avoid arbitrary tinkering. Its inter-project triggers will enable better componentisation of our product and slicker regression testing. Via distributed builds, the server throughput can grow to meet expanding demand. And finally Hudson is better able to manage completed builds, preserving important releases against careless deletion.

No single tool provides a panacea and there are quite possibly other tools that have their own particular benefits. However, in the limited scope of the comparison between the two tools presented here, the winner is clearly Hudson.

Further Reading



The Hudson project was forked during an uncertain period when its new owners (Oracle) were unsure of their intended direction.  The new project is called Jenkins and is very similar to Hudson.  Probably a majority of Hudson’s mind-share followed the fork to the new Jenkins, where development continues to be active.

comments powered by Disqus