Hudson – Continuous Integration Tool

In my current position, we use perl extensively. There isn’t much of a build process — check out the code, set a couple variables, run a suite of tests. (There is always the perl -c command line option which will perform a syntax check but I want something more exhaustive.) A former colleague of mind pointed me at Hudson, a tool they recently started using. They are a java shop and Hudson is definitely aimed at java shops. Below are the details of my initial experience with Hudson.

Proof of Concept

I downloaded the Hudson WAR file (version 1.176) to my desktop machine. From a command line prompt, I launched Hudson with the command java -jar hudson.jar. I minimized the command prompt window and launched my browser to the default http:\\localhost:8080 which displays the Hudson configuration pages. Here, I created a new job and filled in the following:

  • Project Name
  • Project Description
  • Subversion Repository URL
  • WebSVN URL
  • Set up poll SCM (check for updates) on once a minute schedule)
  • Selected execute Windows batch commands with the necessary commands to run my perl tests
  • Select email notification

That is pretty much what ot took to get up and running. I had a few mistakes in the commands under “Windows Batch Commands” but once that was complete, I was able to get a successful build. (Here successful is defined as the last command executed returning with a non-zero exit code.) The email did not work at first. I needed to go back to the home page and select “Manage Hudson”, “System Configuration” to then set up my email server credentials.

I thought all was well until my first unattended build. The build failed with the message “ERROR: Failed to update…” from the Subversion checkout. I did some research and found some references to the same error in one of the packages that Hudson uses. There was a suggested fix but it required I code change. I filed a bug and a new build was available within a couple of days which fixed my problem.

Move into Production

After running the build on my local machine for a few days, I decided it was worth moving into our normal processes. I installed it on a Windows server. There is a good description on how to setup Hudson as a Windows service in the Hudson wiki.

We have been running Hudson now for a few weeks and I am very pleased. Highly recommended.

 

Accidental Correctness and Auto Increment Database Identifiers

I recently ran into a couple of bugs that we should have found in our development, test and staging environments. However, they slipped through into our production environment. These were not major issues, just a couple of helper utilities. We thought they were working fine. When we tested the utilities they behaved correctly.

This was just luck of the draw. We had done our testing with clean databases — databases in which the various primary key id all started at an auto increment value of 1. Since, all of the inserted data started at the same id value, the functionality accidentally worked.

We considered a couple of approaches to prevent this from happening again. We already have a copy of our production data that we use for some testing. This is not always feasible since the amount of production data results in a substantial setup time. Most of the time, we will use the same scripts we have always used to create a clean database. However, we added an additional step to the scripts where they set the auto increment starting values for each table at 10,000 value increments from each other. This will prevent us from “accidentally” thinking our application is working.

 

Humor – And God Wrote in Lisp Code

I recently heard a recording of a parody of Julia Ecklar’s “God Lives on Terra” (which I am not familiar with) entitled “God Wrote in Lisp Code”. The lyrics are copyrighted 1996 by Bob Kanefsky. Being nearly 12 years old, I am surprised I did not see this before – perhaps I was actively ignoring anything dealing with lisp at the time. The lyrics can be found on gnu.org. Funny.