Continuous Integration - Just another buzz word?

Therefore, this month we will talk about Continuous Integration - is it just another buzz word? We will discuss in detail what Continuous Integration is, what's required to implement continuous integration, and what value it brings to the project.

What is Continuous Integration?

One of the most common activities for SCM practitioners is the software build process. The objective is to create reliable releases of the software in a predictable way. The Continuous Integration approach was created to assist in this endeavor.

Continuous Integration holds the developer responsible for their code changes integrating with other developer's code in the repository before checking it in. Second, Continuous Integration recommends periodically executing a build against the latest source code on a clean build machine for the sole purpose of running tests against the software to identify integration problems as early in the process as possible. The results of these builds are for developer use only as a feedback loop to some quality measure of the latest source code in the SCM repository. If the tests do not pass, the developer is responsible to either back out their change, or to fix the problem and re-integrate.

Continuous Integration primarily effects the software development process, but must be supported by the SCM components of version management providing an easy way to update the private workspace, and an integration build script which controls the integration build. The more often integration builds are scheduled, the better - several times per day is typical. Developers that check in and integrate several times per day have less change to integrate than developers who wait for weeks before updating their workspaces and/or check in their changes. When a developer is ready to check in a changed file to the SCM repository, the first step is to always update her workspace with the latest code from the repository. She then will perform a private workspace build, and finish by executing adequate smoke tests and/or integration tests. If the tests pass, then and only then may she check in her code.

The second part of Continuous Integration is the automated Integration Build. Again supported by SCM, the automated integration build runs periodically, say every hour, on a sanitized build machine. The build starts by getting the latest code from the repository, builds it in its build area, then runs a series of automated smoke and/or integration tests against the release. The results are then made available via an intranet web site and/or email.

For Continuous Integration to be effective, it is very dependent on two main factors: A completely automated build, and some form of automated tests.

The Automated Build

A fully automated build process can bring many benefits to a project including more predictable releases, shorter build times, documented and versioned process for building the application through the build script itself, and the ability to schedule a build without manual intervention. As stated earlier, Continuous Integration depends on an effective automated build system being put in place.

An effective automated build is one that addresses build-time dependencies when figuring out what objects to compile. This is especially important when using Continuous Integration on larger projects because this type of build system will only build the objects that are affected by the objects that have changed since the last build. Tools such as Openmake, Jam, Ant, and make all handle these dependency conditions quite well.

Once you have your build fully automated, it can be wrapped with scripts to implement a consistent private workspace build, fully automated integration builds, and a completely automated formal release build.

Automated Tests

The second component