One of the hardest things to do in any development project is keeping on track. Many software projects end up going off in unexpected directions, both from a technical perspective and from a business one. Modules built by different developers can be difficult to integrate. Lack of visibility of the application being coded often leads to an ever-widening gap between what the user expects and what the development team actually builds.

Continuous Integration can help your project in both regards, as it is a powerful technique that can be used to make your development process smoother, more visible, and less risky.

If there is one technique that can revolutionize your development process, it is Continuous Integration.

The underlying principle of Continuous Integration is simple: integrate early, and integrate often. Continuous Integration has been around for at least 10 years, although more recently it has been brought into the spotlight by Agile methodologies.

So what is Continuous Integration anyway? Continuous Integration is based on the observation that the longer you wait to integrate your team’s code, the harder it gets. In many projects, a typical development lifecycle goes something like this. Initially, coding goes along just fine; there may even be unit tests to prove it! Then, at some point in time, the team leader decides (or reminds everyone) that a delivery is due in a couple of weeks. It may be just an alpha or a prototype, but it is a delivery nevertheless. So it’s all hands on deck to get something working for the due deadline. The problem is, when I check out my code, it doesn’t compile any more! Of course, I know that my code is OK, so it’s probably some other developer’s fault—maybe they forgot to commit a class, or changed one of my interfaces without asking my permission…oh, yeah, and some of the unit tests no longer work, but they belong to the DB team down the corridor, so I won’t worry about them too much…and so on.

This widely observed phenomenon is known in Agile circles and elsewhere as “Integration Hell.”

Continous Integration is the antidote to Integration Hell. It offers a powerful way to detect bugs and conflicts early so that they can be fixed quickly and easily and without too much bloodshed among team members. It basically involves automatically building and testing code at regular intervals. Team members commit their code to version control very frequently (at least on a daily basis). A central server regularly checks out the latest version of the project source code, and runs a complete build, including compilation and tests. The build process automatically notifies team members of any build failures, and (hopefully) the team member responsible for commiting faulty or conflicting code will immediately jump out of his chair (figuratively speaking) and rush off to fix the problem before anyone else notices!

This practice is first and foremost a risk-reduction strategy, ensuring that the application integrates correctly at all times and reducing the risk of integration issues appearing late in the project. Additional benefits include improving communication between team members and reducing the time needed to prepare a release. Indeed, in a project using Continuous Integration, you virtually always have a demonstratable, if not deliverable, version of the application running somewhere.

However, Continuous Integration goes much further than simply ensuring that your application builds correctly at all times. Continuous Integration means that you always (well, almost always) have a working version of your application to show to testers, users, and project sponsors. Don’t underestimate the benefits that this can have on your project. This means that, at any point, you can demonstrate a particular feature, and get fast, early feedback from testers and end users. Users and sponsors get better visibility on the application’s features and on the project’s real progress, and potential issues are raised (and fixed) sooner rather than later.

Now, in practice, a Continuous Integration process can be automated to varying degrees. Some teams use a largely manual process; once developers have completed a task, they run an integration build using an automated build on a separate integration build machine. Other teams use a Continuous Integration tool such as CruiseControl to automate the process.

The most fundamental feature of any Continuous Integration tool is the automatic build cycle. The Continuous Integration tool, either at a scheduled point in time or whenever any changes are detected in the source code repository, fetches the source code’s latest version and attempts to build and test the project. If the build fails, developers can be notified in any number of ways: e-mail, instant messaging, telepathy, courier pigeon, or through some other, more exotic, notification technique.

There are many Continuous Integration tools, both open source and commercial, on the market, and deciding which one would best suit your particular environment can prove difficult. Some Continuous Integration tools also boast additional SDLC features, such as release management and build artifact management, whereas others concentrate on core Continuous Integration functionalities. Some try to provide a wide range of notification methods and support virtually every version control system under the sun, whereas others concentrate on delivering a small, light, easy-to-understand product.

In this part, we will look at four of the more interesting open source Continous Integration tools: Continuum, CruiseControl, LuntBuild, and Hudson.

Continuum is a simple, lightweight, web-based Continuous Integration tool. It is easy to install and involves little initial configuration. On the downside, it is not as feature-rich as some of the other tools, and the user interface is a little clunky.

CruiseControl is a mature and robust Java Continuous Integration tool that enjoys a strong user base and a solid industry reputation. It supports virtually any type of project, be it Ant, Maven, Maven 2, make, or just a plain-old command line script, as well as a wide range of SCM (source configuration management) tools. Its notification techniques are second to none, and it can integrate easily with anything from a mail server to a Lava Lamp. It also benefits from a large number of third-party plug-ins. On the downside, it is much harder to set up, to configure, and to maintain than any of the other tools, and the user interface is somewhat unappealing.

Luntbuild is another open source Continuous Integration tool written in Java. It is fairly easy to install and configure, and, like Continuum, all server administration tasks are done via a (somewhat clunky) web-based administration console. Luntbuild is designed to do more than just manage the continuous integration process: it also lets you store and manage generated artifacts, label and promote versions, and manage dependencies between builds. It supports a wide range of version control tools, and notifications can be diffused via e-mail, IM, and even on a blog site.

The last product on our list, Hudson, is a relative newcomer to the Continuous Integration field, but it is one that is rapidly gaining a substantial following over the last year or so. Hudson is entirely web-based and has a pleasant and very functional user interface. Hudson supports fewer SCM products than the other tools we have seen, concentrating exclusively on Subversion and CVS-based projects. By contrast, it comes with many useful advanced features not seen on some of the other tools, such as parallel builds, inter-project dependencies, graphical build statistics, and the storage of build artifacts. Hudson also benefits from a large and increasing library of plug-ins, allowing integration with a wide variety of other tools, including static analysis data from Checkstyle, PMD and FindBugs, test coverage statistics using Cobertura or Emma, and issue management systems such as JIRA and Trac. To date, Hudson is probably one of the most innovative of the open source Continuous Integration tools.

Finally, although it is not in the scope of this book to discuss commercial products in any detail, some are worth a mention. Over the past few years, a number of high-quality commercial Continuous Integration tools have emerged, such as TeamCity (from JetBrains), Bamboo (from Atlassian), and Pulse (from Zutubi). These “next-generation” Continuous Integration tools propose slick user interfaces, integration with lots of other products, and interesting new features such as the ability to build and test an application before it is committed to the source code repository. This strategy preemptively prevents broken builds being ever placed in the source code repository.

For any readers interested in learning more about Continuous Integration as a process, I would recommend the excellent book Continuous Integration (Addison-Wesley), by Paul Duvall, Steve Matyas, and Andrew Glover.

Finally, in this section we will also look at Openfire, an open source Java instant messaging tool that can be a useful addition to your Continous Integration infrastructure.