Continuous Integration (CI), as the name suggests, is a Software Development Methodology where the emphasis is laid on integrating the system on-the-fly. That is to say, the practice of component or module integration being a one time event is discouraged. Instead, component or module integration forms and integral part of the build cycle.
The concept of continuously integrating the code was introduced, as an offshoot of Extreme Programming by Martin Fowler and Kent Beck. In his paper, Fowler talks about the advantages of the agility that comes-in along CI, with the benefit of always having a version of running code (that is integrated, built, and tested) at the everyone’s disposal. Fowler also promotes the idea of integration being a non-event, as against the traditional one-time integration and build activity, in which a number of unforeseen dependencies might cause a problem.
CI is a concept, which does not mandate a need for a tool to be implemented. Yet there are numerous tools available, many of them open source, which facilitate the implementation of CI with considerable ease. Whether to manually manage the CI, or do it with the help of a tool, is at an individual’s discretion, which could be based upon various factors like time and resources.
It should be noted though that CI should be seen as a mindset, an approach, rather than a tool or a framework. Some people have been quite vocal about this.
Of the several tools available for CI, we’ll discuss one called CruiseControl (CC) that was introduced by ThoughtWorks. CC allows the implementation all the aspects of CI that Fowler had mentioned in his paper, including self-testing code (a term coined by Fowler), artifact archiving and, seamless integration with version control environments, to name a few.
Let’s now go through each of the practices that CI suggests, and evaluate how a tool like CruiseControl could help us in it:
One of the key features of CC is it’s the ability to handle multiple project configurations via a single interface. Users could switch between different projects and handle each separately. Each project has a separate build in the CC work directory so that project-level alterations can be managed independently.
Integration with Versioning Environment
CI seems apt for a development structures where we typically have relatively smaller teams, working on a project. In fact, one of the tenets of XP is that, project team should be small (~5-10 people). Since CI strongly emphasises on the concept of continuously checking-in the code, thinking in a wider perspective, we could see this as a way to measure individual throughput, with the advantage of being able to highlight the concept of code modularisation, and embedding that in developers’ minds. CC integrates with most of the popular (and proprietary) versioning tools.
When we said continuously checking-in above, it has to be clearly understood that the main line of code (Trunk/Root) must always have the latest build, which should _never_ break. The importance of having non-breaking code in the repository main line (Trunk/Root) could not be emphasised less. It is implicit, and understood that the code checked-in in the mainline in the repository can never break. Since each committer would check-in the code only after testing — first in his/her local environment, and then after integrating with the latest code from the trunk — the chances of encountering surprises in the main build are greatly reduced.
Such test-driven development is strongly recommended by CI.
CC allows the integration of JUnit test cases (which could be thought of as sanity tests) to be carried out in the main build, as soon as a commit is detected. Once the CC build is over, the results are published, and could also be mailed to all the concerned parties. Such features help in timely detection of any broken builds, and initiation of remedial actions, if required, thereby.
Making the Mainline Unbreakable
The role of versioning tools in a software project is indispensable. This is true even for projects where CI is not being adopted. Fowler strongly emphasises on the idea of the putting everything useful in the repository. Needless to mention, when we say ‘everything useful’ we exclude things like executables, and generated files. The idea is to be able to build the entire system on a virgin machine, without any hiccup.
All the required dependencies for being able to build the project should be available within the repository, so that anyone could perform a basic repository mainline checkout, and build the entire system.
With CC, this recommendation of CI can be addressed by making project-specific builds, that may call an in-project build of the entire system, after having performed an update from the versioning environment. That is, the build should first perform a versioning system update, followed by a build of the entire system. Any artifacts generated, could then be archived within the CC file structure, for further usage.
CI is a software practice that could help us in significantly reducing the risks in the software development cycles. The advantage of this methodology may not be immediate, but there are considerable long-term benefits. With the added advantage of influencing, and aligning the developers’ mindset, to continuously thrive for integration.
CI is not dependent upon a tool to be implemented. However, of the many tools aimed at helping in CI, CruiseControl is one of the most popular, because it allows seamless integration of various aspects of CI.
- http://martinfowler.com/articles/continuousIntegration.html : Martin Fowler’s paper on CI
- http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html : James Shore’s write-up on CI
- http://jamesshore.com/Agile-Book/how_to_be_agile.html : James Shore on How to be Agile
- http://extremeprogramming.org: Extreme Programming
- http://cruisecontrol.sourceforge.net/gettingstarted.html : Get Started on CruiseControl
- http://docs.huihoo.com/cruisecontrol/DrivingOnCruiseControl_Part1.html : CruiseControl installation reference
- http://en.wikipedia.org/wiki/Continuous_Integration : List of various CI tools
 or as Fowler puts it, since the requirements of self-testing code are weaker in CI (they are more to do with Test-Driven Development), testing during CI is more about exploring the design of the system, rather than finding bugs
 a machine where the basic environ
ment (OS, JVM, Server etc) is already installed