The Three Pillars of Continuous Integration

Continuous Integration commonly known as CI is a process that consists of continuously compiling, testing, inspecting, and deploying source code. In any typical CI environment, this means running a new build every time code changes within a version control repository. Martin Fowler describes CI as:

A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

While CI is actually a process, the term Continuous Integration often is associated with three important tools in particular. As shown in the screen above the three pillars of CI are:

1. A version control repository like Subversion, or CVS.

2. A CI Server such as Hudson, or Cruise Control

3. An automated build process like Ant or Nant

So, let’s look at each of these in detail:

Version Control Repository:

Version control repositories also known as SCM (source code management) play a crucial role in any software development environment. They also play a very important role for a successful CI process. The SCM is a central place for the team to store every needed artifact for the project. It is mandatory for the teams to put everything needed for a successful build into this repository. This includes the build scripts, property files, database scripts, all the libraries required to build the software and so on.

The CI Server:

For CI to function properly, we also need to have an automated process that monitors a version control repository and runs a build when any changes are detected. There are several CI servers available, both open source and commercial. Most of them are similar in their basic configuration and monitor a particular version control repository and run builds when any changes are detected.

Some of the most commonly used open source CI servers are; Cruise Control, Continuum, and Hudson. Hudson is particularly interesting because of its ease of configuration and compelling plug-ins, which makes integration with test and static analysis tools much easier.

Automated Build:

The process of CI is about building software often, which is accomplished through the use of a build. A sturdy build strategy is by far the most important aspect of a successful CI process. In the absence of a solid build that does more than compile your code, CI withers. With automated builds, teams can reliably perform (in an automated fashion) otherwise manual tasks like compilation, testing, and even more interesting things like software inspection and deployment.

Now that we have seen the important tools in our CI process, let’s see how a typical CI scenario looks like for a developer:

* CI server is configured to poll the version control repository continuously for changes.
* Developer commits code to the repository.
* CI server detects this change, and retrieves the latest code from the repository.
* This causes the CI server to invoke the build script with the given targets and options.
* If configured, CI Server will send out an e-mail to the specified recipients when a certain important event occurs.
* The CI server continues to poll for changes.

Why is CI Important?

This is one of the most frequently asked questions, and here are a few points to note about this powerful technique:

* Building software often greatly increases the likelihood that you will spot defects early, when they still are relatively manageable.
* Extends defect visibility.
* CI ensures that you have production ready software at every change.
* CI also ensures that you have reduced the risk of integration issues by building software at every change.
* CI server can also be configured to run continuous inspection which can assist the development team in finding potential bugs, bad programming practice, automatically check coding standards, and also provide valuable feedback on the quality of code being written.

Over the past several months, I have assisted several companies in implementing CI. There was a little bit of resistance from the developers in the early stages when we implemented continuous feedback. But, never heard a single negative comment about this approach. If you already have a version control repository and automated builds, you are very close to the CI process.

Download one of the open source CI servers, configure and setup a simple project. It should take less than an hour if you have automated build scripts. Start adding additional features like code inspections, generating reports, metrics, documentation and so on. Most important, send continuous feedback to your team.

Give this process a try, you sure will be surprised to see how effective it is. And, as always share your thoughts, concerns or questions.