Dahlia Bock

Continuous Integration 101

Continuous integration was first talked about by Martin Fowler and Kent Beck back in 1999. That was 11 years ago. But I've come to learn that 11 years is nowhere close enough to making a practice mainstream.

The basic idea behind continuous integration is that if you have a team of developers frequently checking in code to a source control system (well, hopefully you do that), you need a way to verify that the code that has been checked in works seamlessly as a whole. What better way to verifying that than after every commit? And what better way of doing that verification after every commit than automating it?

A typical flow of a CI build is as follows:
1. Compile source code
2. Compile tests
3. Run tests ----> A lot of teams miss this step and what you end up with is just a continuous build which gives you no benefit at all.
4. Package deployable artifacts

(Sometimes these steps include automatic deployment to a test server(s) so that other members of the team like QAs, BAs or customers can play with the application, but that's a story for another day.)

There are many CI tools out there that will help you achieve this goal: Hudson, CruiseControl (CruiseControl.NET, CruiseControl.rb), Bamboo, TeamCity, etc. My favorite of those tools is Hudson because it is extremely easy to set up and you will be up and running in about half an hour, and it's free.

So why is Continuous Integration a valuable practice?

1. It verifies your code works as a unified whole, that is if you have tests and run them. It is much more critical that integration is done sooner and continuously when development is spread out over separate teams.
2. It produces a deployable artifact for someone to actually see working. This eases the effort to doing frequent deployments and opens up the possibility of automating that process as well.