Continuous Integration Tools

Continuous Integration Tools Generations

Early adopters of Agile did continuous integration using cruise control. This java based tool inspired developers using other development platform to create specific implementations like CruiseControl.NET, CC.rb, etc. These tools provided the same feature set and didn't allow too many options for modeling the continuous integration build. But they were extremely easy to understand and use, and they changed the way software was developed. These were in affect first generation of continuous integration implementation.

Features in first generation tools

Support for multiple source control types

Ability to publish build results to different channels

Ability to use different build tools and define jobs

Pluggable architecture to define custom source control types, publishers, result formatters

As the first generation tools became stable and useful they were also creating demand for new features. Lowering the build time by using multiple computing units, ability to abstract continuous integration builds based on architecture elements and extending the continuous integration to software deployment and connecting deployment and build. While the first generation tools could be hacked to achieve these to some extent but it became quite clear that the whole problem needs to be re-looked.

Another things people noticed that like we do not need svn.java, svn.net, svn.rb we do not need continuous integration tools built on top of each application development platform. To address all of these we witnessed emergence of tools like Cruise, TeamCity and Hudson, which form the second generation. But there is significant difference between these tools, which would see in detail when looking at the patterns.

Features provided by second generation continuous integration servers on top of features provided by first generation ones.

Build distribution to different machines

Build time as I have pointed earlier is one of the most critical requirement from the continuous integration. This requires the ability to break down a huge build into smaller units (jobs) and distribute them to different machines.

Association between build executions and source control revision

Build distribution requires that these different build jobs run for the same version of the source code. Continuous integration server manages this association when distributing the jobs across different environments.

Ability to design build as jobs, stages and pipelines

While these options are available to design your continuous integration, they work under the constraints provided by the structure of the codebase, software architecture, team size and release duration. So, while the above features are available in second generation tools one cannot apply them to achieve everything. For example, one cannot scale out the build, reducing the build time if the architecture of the application being built is monolithic in nature.