I was playing with Hudson today in what I would call a non-standard, maybe non-friendly Linux box. The first time I setup Hudson, Java and Ant were installed in the standard locations; once I configured my projects, Hudson just went to work. On the non-standard box, nothing was installed in the expected locations, fortunately this was no big deal. The Hudson configuration options are simple and numerous. The system level configuration page has options to configure the JDK, Ant, Maven, Shell, and email settings; which are all specific to the machine that Hudson is installed on. At first, I thought this might be limiting, as very few projects use the same version of these tools. Luckily, the configuration page has the ability to specify the JAVA_HOME and ANT_HOME for multiple versions of each tool. This allows each project to specify which version of the tool they want to use in their build process, pretty simple.
One of the more interesting system level configurations addresses Hudson’s security. There are five different security options, from no security to per-project security. For authentication, I configured Hudson to use an LDAP server. This took a little trial and error, as this feature does not seem to be well documented. Fortunately, it only took a couple of attempts and the login screen started working. I chose to implement project-based security; this allowed me to delegate the responsibility of each user’s role to the project’s owner. This seemed like a good approach for limiting the amount of work required by the Hudson administrator. There could be simpler configurations, especially if you wanted to manage fewer people, but this approach gave me the finest grain control over each person’s ability… which might actally be overkill is practice. I would really need to see this working on a real project before I would be able to suggest the best security option, but it would seem to work in multiple environments.
The final step is to create and configure an individual project, which is also very straight forward. First, you pick the version control system and enter the repository and access information. Next, select the Ant-based project option and type in the Ant target name that is responsible for the continuous integration. There are multiple options you can configure here as well, but that is all I needed to start the process. Because Java and Ant were not installed in their normal locations, I selected the appropriate versions, as configured in the system level. That was it. I hit the build button and off it went. Hudson provides all kinds of visual feedback on the dashboard, letting you know exactly what is building, and even predicts how long until the current build finishes. One of the more interesting features is the ability to watch the build from within the dashboard (web page). Hudson uses AJAX to capture the log file of the running Ant process and shows a live update to the user. Pretty cool, it is no different than running Ant in a local shell!
This tool seems significantly simpler to get working than Cruise Control. I really like that fact that every project can be configured to match its own requirements. Some projects might want to use Checkstyle and PMD, another project might want to use FindBugs; not a problem. Once the plug-ins are installed by the administrator, Hudson makes them available to each project and automatically published the collected results. Because of this project centric view, it is even easier to integrate with multiple version control systems, each project simply chooses the appropriate back-end.
I did want to mention that Hudson seems to be a tool that extends beyond the typical developer requirements. As I mentioned in a previous post, QA groups can also use Hudson for activities other than continuous integration. One interesting feature is Hudson’s ability to monitor external jobs. This allows you to record the execution of a process run outside Hudson, even on a remote machine. It was designed so that you can use Hudson as a dashboard of your existing automation system. Hudson even have multi-server scalability built-in. This allows the environment to be configured with helper machines to distribute the processing load, taking advantage of the remote resources, while centrally managing and monitoring the process.
Hudson appears to have been pretty well thought out. Hopefully someday soon, I can use it for real!
