Continuous integration servers have been around for a long time. It consists of build engines integrated with a source tree, and in a perfect world, has hooks to execute unit tests once a successful build is achieved. With Extreme Programming, tools such as Cruise Control was released in 2001, were adapted to implement this process.
Since that time the value of automated continuous integration has grown. I know of development efforts, using traditional lifecycle strategies, who experience great value from Continuous Integration. The reason for this success is that continuous integration, at the core, simply confirms the stability of the code at any particular point in time. Can it be compiled? If so, does it work.
As the success of continuous integration grew, so did the number of tools used to automate continuous integration. Today I was reviewing a web site that was surveying the use of build tools in use today. The project identified 20 different CI tools and gathered statistics for who is using what engine. The graph they present is interesting, representing what is currently in use, and what tools are targeted in the future. What I find most interesting is that most of these tools have some presence as open software.
Take a look at the results of the survey at this InfoQ Survey..
Personally, I have become so attached to the value of CI that it is the first thing I create in a project, once I have a base application that can compile. Having CI from day 1 of a project is invaluable.
Are you using CI effectively? Do you have a preferred tool? What advice would you share about Ci? You can do so in our comments, or drop me a note at btaylor@sswug.org to include in a future editorial.
Cheers,
Ben