24 March 2006
Better Code Automagically, Part 2: Continuous Integration
This post is the second in a series (part1 here) of discussions around mechanisms for increasing code-quality thru the use of automated tools– the ultimate goal being an increase in overall code-quality and a decrease in manual Q&A time.
Lets first talk about the concept of Continuous Integration itself. The idea is pretty straightforward:
Create an automated process that regularly (i.e., at scheduled intervals) accesses the source tree and:
- Compiles it
- Runs tests on it
- Notifies interested parties of the results.
That’s about it. CI is a core tenet of XP and agile development practices, (although its certainly safe to say that numerous non-agile development shops have been doing a variant of the above for years)
We will get to the implementation details shortly, but its worth mentioning that the above simple list implies several prerequisites:
- The source tree is centrally accessible; and moreover it needs to be accessible outside of an IDE. Any modern version control system will allow for this (CVS, SubVersion, etc)
- Build scripts exist independent of any IDE. In our case we will assume the appropriate ant build files have been created in ant.
- Unit tests have been created (junit) and are part of the source tree, and there are the appropriate hooks in the ant file to explicitly run a suite of tests.
A CI tool allows for the automatic application of the the above mentioned goals, and immediately realizes the following gains:
- A drastic reduction in liklihood of a ‘John-checked-in-a-change-and-then-went-on-vacation-for-a-week‘ type errors. The classic case here would be a failure of a developer (John in this case) to check in a new file upon which there relies a dependency. Everything works fine on Johns’ local box, but breaks anyone that pulls the latest code from the version control repository.
- Because the code is unit tested (in addition to simply compiled), on regular intervals, coding changes that result in breaking previously working code are identified immediately upon committal to the source tree– which is when they are the easiest and most cost effective to fix.
- A failure in the CI run, for any reason, results in an email sent to a list of observers; who can immediately take corrective action.
CI is not rocket science, but there are a couple of fundamental keys that are mandatory to a successful CI strategy:
- Good unit test coverage is essential. Compiling your code alone does not represent a diligent test of your system.
- Code needs to be checked in early and often. This is a fundamental rule in XP , and in the case of CI, its required. The longer a developer holds on to his/her code, the greater the delta potential is. (This is balanced, of course, by the thou shalt not check in crap code commandment)
- Run your CI build often. Really often. Several times an hour is ideal.
OK, the only thing that is left is to pick a platform upon which to implement the above. I personally favor anthill because it caters specifically to a Java crowd (They offer a commercial and OpenSource variant.) Setup is straightforward and fairly obvious. The application is deployed as a war into your favorite servlet container, and is managed by a decent web UI. As part of the configuration is a list of email addresses that represent the interested parties… which is typically set to a development mailing list.
Another popular CI tool is CruiseControl, which has the advantage of supporting languages other than Java (and I don’t doubt their are numerous additional tools that I am unfamiliar with.. please comment and help educate me!)
While an admittedly high-level overview of Continuous Integration, my hopes are that the value of the approach is clear. CI in some form has become absolutely fundamental to any software project that ALTERthought undertakes, and second only to perhaps a test infected methodology in core paradigms.
Technorati Tags: java, findbugs, agile programming, continuous integration
