Have you experienced Integration Hell? Do you find that sometimes broken code gets into the mainline without anyone noticing?

These practices can occur frequently. A way to combat this is to adopt the mindset of Continuous Integration (CI).

Background

CI is a development methodology involving daily developer integrations verified by automated builds. Martin Fowler wrote the original article on CI:

"Continuous Integration is 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 (including test) 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" martinfowler.com

The Fowler article highlights that adopting CI represents a sizable shift in the process of building software. Integration usually happens infrequently, resulting in a small effort today being replaced with a lot of pain later.

CI changes the developer approach by encouraging frequent integration as part of their daily activities.

Risks of not doing CI

  • Without CI the team can lack cohesion (incompatible conflicts, different libraries in use, "I thought you fixed that bug 3 months ago!").
  • Lack of Visibility: Not knowing when a build fails or your code coverage.
  • Isolation: "It works on my machine!".
  • Integrating late means fixing bugs late, which is costly.

Benefits of CI

  • CI allows you to develop software faster, better and cheaper.
  • Faster: No integration points. Release builds become a non-event.
  • Better: Tested early and often. Consolidated metrics though a CI Server.
  • Cheaper: Identify defects earlier and fix when least costly.
  • Easily repeatable testing.

Prerequisites to adopting CI

In order to take advantage of CI you will need to already have your source code in a repository such as Subversion or Clearcase. You will also need to have adopted an automated build tool such as make, maven or an equivalent.

The biggest benefit you can get from CI is when you have a suite of automated unit tests. If you don't have unit tests then you will only have the validation that your code can compile, not that it functions as expected.

CI will not work if you want to use:

  • Nightly Builds.
  • Developer Branches.
  • Scheduled Integration.
  • Building via an IDE.

If you can match these prerequisites then you will be able to take advantage of a CI with a CI Server.

CI Servers

A CI Server acts as a centralised build machine for your project. It is possible to practice CI without a CI Server but it isn't advised. CI Servers give you a web interface that allows you to see the status of your project within different environments.

To get started with a CI server you make a job which knows where your codebase lives. You then give it a simple script which can be run from the command line. The CI Server will then continuously poll your source code repository for changes, if it detects a change then it will check out your codebase and run your build tool. It will then report back the result of the build including if anything has broken.

CI Servers offer different mechanisms for reporting feedback on builds. A few common options are email, instant messaging, RSS, IDE integration and tray icons.

This feedback gives developers confidence that their changes are working with everyone else's and allows them to continue to develop with that reassurance. This is especially important when a developer is performing a large refactoring task.

Rules for CI

In order to get the most out of CI, there are some rules that you need to follow:

  • Commit early and commit often.
  • Never commit broken code.
  • Fix build failures immediately.
  • Ensure your builds run fast, and fail fast.
  • Avoid known CI Anti Patterns.

CI within organizations today

CI is a development methodology which takes getting used to, but it allows you to develop software faster, better and cheaper. Teams within organizations are building software in a CI Server as you read this.

While the choice of CI Server differs within organizations, Hudson is getting a lot of support as it is free and has a large community creating extensions.