Continuous Integration with Hudson

Today I learned about continuous integration using the Hudson server system and before this I didn't know anything about continuous integration. It was pretty simple for me to get up and running by just following the tutorial on this site (just make sure you register on IBM first). It may take longer though if you do not already have some prerequisite software installed such as the Java JDK, ANT, and JUnit.

Continuous integration (CI) is a process where projects are automatically built to make sure that any issues encountered will be detected as early as possible in the software development cycle. This automated process requires various types of tools to work. The minimum tools required are an automated build system, a testing framework, and a code repository. Other tools can be used as well to increase the quality of the project such as PMD and FindBugs. For my trial of Hudson, I used the Ant build system, JUnit test framework, and subversion code repository.

So the way the CI process works is pretty simple. The user specifies the code repository's url, when and how often the repository must be checked for a new build version of the project, and then it is downloaded, built, and tested when a new version is found. It's such a simple process to run, but its usefulness and success depends a lot on the developers.

The process of CI alone will not ensure a quality system. There are practices called anti-patterns in this article that developers follow that can make CI a failure for them. A couple of the anti-patterns mentioned in the article that I find myself guilty of doing:

• Checking code in to the repository infrequently. The idea behind this is that code should be checked in frequently so that other team members know what's going on with development and allow them to give their own input before changes go too far.
• Submitting broken code. Broken code can remain unfixed for a long time even if other members try to fix it, but it can also hold up development in the long run.

Hudson Installation
As I mentioned earlier, I used Hudson to get a feel for continuous integration. Installation was pretty simple and the only problem I ran into, which was pretty stupid, was when I couldn't get Hudson to load on my system after using the "java -jar hudson.war" command. At the time I had my Apache HTTP server running, and it too was using port 8080. After a few minutes (yes it took me minutes) to realize that I could just stop the server! The rest of the Hudson installation and configuration went smoothly afterwards. Oh, and I used the ambientHackystat project to test out Hudson.

CSDL Hudson Server
Getting the ambientHackystat project working on the CSDL server won't take much effort since it is a Java project. I suspect that the server is already setup with Ant and JUnit so all that's left to do is create a new project, specify the subversion repository url, the interval for Hudson to check the ambientHackystat code repository, that Ant should be executed when Hudson has downloaded the recent build, then specify the location for the test reports xml file.