The Disco Blog

The process of Continuous Integration (or CI, man) is about building software components often– in many instances, this means anytime code within a hip repository (such as Subversion, ClearCase, Perforce, etc) changes. The benefit of CI is simple: by building software often, issues can be found early as opposed to later in a software developmental life-cycle where issues (like defects) are more expensive to address. 


While CI is a process, the term often gets associated with a tool– but please keep in mind that CI is much more than a tool, man. In fact, the tool is probably the least important aspect of CI, because all the tool does it run your hip build (which, as you’ll find, is far more important) when a change is detected within a code repository.

Getting started in Continuous Integration then requires three things, baby:

1. An automated build process with a platform like Ant or Maven, for example
2. A code repository, like Subversion
3. A CI server such as Hudson, CruiseControl, LuntBuild, etc, although a cron job can suffice

As the process of Continuous Integration is about integrating software often, it stands to reason that the integration of software is fulfilled through the concept of a build. In the Java world, Ant stands as the ubiquitous build platform. With Ant, you can reliably perform (in an automated fashion) otherwise manual tasks like compilation, testing, and even more interesting things like software inspections and deployments. There are plenty of players in this space– Maven, Raven, etc so don’t get hung up on needing Ant, man. Once everything has been wired together though, your build strategy is by far the most important aspect of a successful CI process– without a solid build that does more than compilation, CI will wither in the absence of something interesting to do (almost like Rock music in the face of a Disco inferno).

Next, for CI to properly take shape, a repository for storing code (or SCM) must be in place to monitor. Essentially, a hip CI server polls a given SCM for changes; consequently, if any are found, the CI server will perform a checkout (or an update of a local sandbox) and execute a build (which is, more often than not, the same build developers can also execute in their local environment).

Lastly, for a copasetic CI process, it helps to have an actual automated process that monitors an SCM and runs builds when changes are detected. There are a host of CI servers available for the Java platform both open source and commercial– all are similar in their basic configuration, that is that they aim to monitor a particular SCM and run builds when changes are detected. They all differ with various bells and whistles; Hudson for example, is particularly interesting given its ease of configuration and its compelling plug-ins, which provide increased visibility into such aspects as test result trends, for instance.

The process of CI isn’t all that esoteric after all is it, man? Three simple things are needed and you are disco dancing– of course, as I’ve mused about before, CI is really about your build process. If that isn’t copasetic, spend time making builds a non-event and life will be trippin’. Dig it?