The Best Continuous Integration Tools

Wednesday Feb 18th 2009 by Vlad Kofman

Discover the practice of continuous integration and several of the most popular tools, including Apache's Continuum, Cruise Control (CC), and Hudson, which effectively implement this concept.

In modern enterprise development, a complex project scope is very common. In this article, I will talk about the latest continuous instigation tools such as Apache's Continuum, Cruise Control (CC), and Hudson; all of them are designed to deal with project complexity, streamline build process, and report issues with the code as soon as they occur. They are perfect for use in an enterprise environment with large to medium size teams, may require a dedicated machine, and provide visual dashboards. These tools also enforce the process of continuous integration and are tightly coupled with a source control system, such as CVS, Subversion, and so forth. They may also simplify code maintenance and reduce the number of the issues that need to be fixed during the QA cycles.

The Continuous Integration Process Defined

The term "continuous integration" refers to a process that builds and tests code on a frequent basis. It was coined by Martin Fowler and Kent Beck, who first wrote about this process near the turn of the millennium.

The continuous integration servers constantly monitor source code repositories and as soon as new changes/commits are detected, they initiate a new build cycle. The build cycle actually involves code compilation and, in addition, may involve various tests and code analysis. If the process encounters errors, it may notify the build master or the culprit who checked in broken/invalid code.

The process can be summarized in these four steps:

  1. Team members check in code artifacts into the source control repository.
  2. The automated build server constantly monitors the repository.
  3. New code is continuously checked out [by this server].
  4. A new project build is continuously integrated and any issues are reported in real time.

There is much more to this concept and to the actual implementation of these automated build servers&mdahsor continuous integration tools—such as definitions of best practices for the code structure, check-in locations, and so on. For instance, the process specifies that all working code should be in the main branch (trunk) of the code repository, and even though various tools can work with multiple branches, it is not recommended to do that.

Continuous Integration Tools

All continuous integration tools consist of a core engine that is designed to monitor and check out various artifacts that are needed to build the project from the source repository. On top of that, some tools can run automated scripts that can be extended to do much more robust functions then just code compilation.

For example, if the tool can run ANT scripts, developers may write their own script to FTP successful builds to a specific location, at the end of the build cycle.

Click here for a larger image.

Figure 1: Hudson Ant Configuration

The core of any continuous integration server is usually exposed via a UI control panel or dashboard (web-based or stand alone). Depending on the vendor, the tools also can offer other features, such as analysis of the code, execution of ANT scripts, configuration via command line or XML, statistics on the code quality, RSS feeds to see various processes and their outcome, and email functionality on the status of the build to the build master or specific people who broke the code.

As I mentioned, most of these tools support and tightly integrate with the most popular source control repositories, such as CVS, Subversion, SourceSafe, and the like to continuously monitor for the new code changes.

Cruise Control, Continuum, and Hudson

The most popular tools are Apache's Continuum, Cruise Control (CC), and Hudson. They are all free open source tools and have varying developer base support. All three tools have the ability to build and test code per a configurable schedule.

Hudson and Apache's Continuum are primarily designed for Java, and Cruise Control (CC) supports both Java and .Net (with the CC.Net version). Because these tools are designed to be very flexible, it's possible to extend them to support build processes in other development languages. For example, Hudson can be extended via plug-ins to work with C#, Python, Maven, Ruby, and others.

Cruise Control (CC)

Cruise Control is a free continuous integration tool designed for Java, but there is a version designed for .NET as well (Cruise Control .Net). All configurations are done via an XML file and there is a web dashboard component that can be installed to view the build progress. Compared to the other tools, CC does not have a configuration UI. This means that you have to look for special editors that can work with CC's config file if you don't want to edit XML by hand. (You can install CCNetConfig program, which helps somewhat with the XML writing). CC also has the most primitive web UI, and high learning curve; however, once installed and properly configured, it proves to be very powerful.

Click here for a larger image.

Figure 2: Cruise Control. NET (CC) build dashboard

The web dashboard does not let you configure the build process, but only allows monitoring it and executing various operations. So, for the initial setup (and any changes), you have to roll up your sleeves and start updating the XML config file.

Click here for a larger image.

Figure 3: Cruise Control (CC) build configuration UI

Cruise Control can be installed as a Windows service, and can execute builds at a predefined schedule. It also can run code analyses, code syntax checks, and compare code against checks.

Overall, the tool is extremely powerful and can be adapted in the enterprise environment with medium to large teams. Its UI is definitely lacking, especially compared with other offerings in this space.

Apache's Continuum

Apache Continuum is an open source continuous integration server that is designed primarily for Java builds. One feature that sets it apart from the other tools is the role-based security. This feature gives you control on what aspects of the build can be seen by specific users. All other main features are similar to Hudson and CC, such as release management, email notification, and integration with popular build tools, such as Maven, and source control management systems, like SVN or CVS.

To install this server, you need to download the tar file and extract its contents to a directory on the machine that will be a build server. Java Runtime also has to be installed on the same box. The initial configuration of Apache Continuum is similar to Cruise Control's, and you need to get your hands dirty with some XML editing. The main file, continuum.xml, is in the conf/ directory.

The operation is fairly straightforward: "continuum start" to start, "continuum status" to check status, and so forth.

The tool's UI is web based, and after the server is up the dashboard can be accessed via a local host link (http://localhost:8080/continuum).

Figure 4: Apache Continuum Dashboard

Click here for a larger image.

Figure 5: Apache Continuum configuration

Note: You can set the tool to generate notifications on failures or successes of the build status. The mail server settings can be configured in the continuum.xml file.


Hudson is another free continuous integration tool designed for Java. It's relatively young, but among the three tools compared in this article, it has the best user interface. Like Continuum, Hudson also has a very short learning curve.

Installating Hudson is even simpler then Continuum, and requires execution of a Java command after the jar file is placed on the machine that will be a build server. Similarly to Continuum, after Hudson starts up, its web-based dashboard can be accessed via a link.

Click here for a larger image.

Figure 6: Hudson Dashboard

Hudson is extremely flexible and the entire configuration is done via UI (no XML editing required). It can be adapted to be used with many development languages, and has plug-in based architecture. It can execute ANT scripts, generate tests, do code analysis, record fingerprints of files, send email to build master or people who broke the build, and so on.

Click here for a larger image.

Figure 7: Hudson Build options

Another very useful feature is an automatic update notification via Hudson's excellent UI, which shows that there are updates available for particular installed plug-ins.

Click here for a larger image.

Figure 8: Hudson Management UI

Similarly to the other tools, Hudson can show visually what artifacts changed between builds and who committed them in to the source control system.

View what artifacts changed since the last build.

Click here for a larger image.

Figure 9: Hudson Build changes


In this article, you have reviewed the process of the continuous integration process and several of the most popular tools that implement this concept. Continuous integration has many advantages:

  • Integration problems are detected and fixed continuously—no last-minute hiatus before release dates
  • Early warning of broken/incompatible code and of conflicting changes
  • Immediate unit testing of all changes
  • Constant availability of a "current" build for testing, demo, or release purposes
  • The immediate impact of checking in incomplete or broken code acts as an incentive to developers to learn to work more incrementally with shorter feedback cycles
  • When unit tests fail, or a bug is discovered, developers might revert the codebase back to a bug-free state, without wasting time debugging

Any enterprise development team involved in a continuous software build process should seriously consider installing one of these tools because they are very valuable in identifying issues with the code as soon as they happen, analyzing the code for correct logic and structure, generating visual issue reports, and reducing the actual build cycle time.

The most popular tools offer a similar set of features, and choosing the right one will depend of the very specific features, such as quality of UI or presence of the role-based security. But, any tool you choose will definitely do the most important tasks of checking out, building, and continuously integrating your code.

References and Online Resources

About the Author

Vlad Kofman is working on enterprise-scale projects for major Wall Street firms. He has also worked on defense contracts for the U.S. government. His main interests are object-oriented programming methodologies, UI, and design patterns.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved