Setting up Hudson for small Teams

Our Java project team has only three developers. We liked the idea to have our tests and builds run automatically and to have a central dashboard. However, we didn’t want to invest much time and expected a continuous integration server to be overkill. But as we started to play around with Hudson, we were quite amazed: the system was up in 5 minutes, including builds, tests, and e-mail notification.

Hudson is an open-source continuous integration server and has drawn a lot of attention since it was awarded with Sun’s Duke’s Choice Awards in 2008. It is nowadays used as the standard build and test environment in many popular projects, including the Eclipse IDE.

Our project setup is very simple: We have a few dozen Unit tests, and we use Ant to run the tests and to build the project. Hudson is a very powerful tool, and we expected it to be overkill for our simple setup. However, we started to play around with it, and voilà: The system was up and running in five minutes, including builds, tests, and e-mail notification!

A screenshot of the basic Hudson dashboard with one project.

In this first article of our Hudson series we would like to share our experience that:

  • Hudson is very easy to start with
  • Hudson is worthwhile to use, even in very simple projects

The focus of this article is on a basic Hudson setup. Advanced features, such as Hudson plugins, will be a subject of the next post.

We do not intend to provide yet another Hudson How-To here, but just to give an impression of how things work, these are the steps to implement Hudson as a build and test environment:

Step 1: You Need a Server

As shown in the figure below, you need a server to run Hudson. We already had access to a server in our network that was used for network testing. As Hudson does not require many system resources, we just installed Hudson there. You could also install Hudson on the server hosting your code repository.

Hudson Network Setup Example

A Setup with the Hudson Server, a code repository and developer's laptops.

Step 2: Download and Start Hudson

Hudson is available for download as a single WAR-file. However, you do not need to deploy an application server to run Hudson, everything you need is included in the file. Just start it using the command

java -jar hudon.war

That’s it. Point your browser to “http://server:8080″, and you see the Hudson Web interface.

Step 3: Configuration

Hudson is configured via the Web interface. There is no need to fiddle around with XML or config files. The Web interface is quite self-explanatory, and has good embedded online help.

The typical configuration steps are

  1. Click on “New Job”, then enter a name for the Job and choose “free-style software project” as the job type. This is the standard job type which allows you to choose everything freely.
  2. Answer some questions such as which source code repository to use (we use Subversion), and which build steps are required (we call Ant targets).
  3. If you want to receive e-mails from Hudson, click on “Manage Hudson” on the start page, and choose “Configure System”. There, you can input the SMTP server to be used when sending mails.

All of this is very easy. You will have your first build running in 5 minutes.

Benefits

When we first installed Hudson, we were mainly interested in a central Web site where we can access the current build versions of our software. However, it turned out that we benefitted a lot more from using Hudson, even in our simple scenario:

  • Clever notification algorithm: when somebody makes a commits and the Unit test fails, Hudson sends out an email only once. There are no repeated mails for repeated failures, and there are no mails to developers who didn’t contribute to the failure. Therefore, it is easy for developers to pay attention to Hudson mails: almost every mail from Hudson means that a new bug was discovered that has to do with your code.
  • Hudson allows for a very short feedback loop. We configured Hudson to check the Source Repository every 30 minutes. That is, if you commit something, integration tests are run on that code not later than 30 minutes after commit. If a build failure is detected, you are notified promptly, and you may fix the failure even before another developer checks out your code.
  • Plugins: Hudson makes it very easy to install plugins. Once started with Hudson, there’s a lot you can do. There is a list of available plugins on the Hudson Web interface, and you can install these plugins directly from that interface. Browsing this list, we found some very useful plugins, such as the FindBugs plugin.

    Over the months, we installed a few of these plugins, and our Hudson now does not only build and test our code, but also help us to improve code quality, and to ease our code review process.

Conclusion

We were very surprised of how easy it is to start with Hudson. And how much you benefit from it, even in small and simple software projects. Hudson helped us to significantly improve our code quality and, by using some plugins, we are now saving a lot of time in our code review process.

However, Hudson is not only easy; it is also a very powerful tool. When your project eventually ends up using different programming languages, and tests need to be run on different operating systems in a test cluster, Hudson will provide support for all this.

For an in-depth introduction to Hudson, we recommend Kohsuke Kawaguchi’s talk at the San Francisco Java User Group.

Share

Leave a Reply

*

4 Responses to “Setting up Hudson for small Teams”

  1. Tony says:

    I had a similar scenario: 3 developers and no CI server. I installed and configured Hudson, integrated it with SVN and Nexus and haven’t regretted it one second. Since our team uses Google Mail and Google Talk exclusively, the Jabber plugin is an excellent way to do notifications of build failures or run commands on Hudson. I did a small blog post on the plugins that found the most useful/entertaining (http://www.stupidjavatricks.com/?p=170). I also have it set up to do hot deploys of certain WAR files to our JBoss dev server, but this behavior is not 100% working because of some problems with JBoss 5. Fantastic CI server. Sometimes it’s hard to believe it’s free.

  2. Nice article. One thing I think is missing is running hudson as a service. This is important because you don’t want to constantly be restarting it if the server gets restarted. Here is part of the way I did it on linux, http://jlorenzen.blogspot.com/2007/10/linux-generic-start-and-stop-scripts.html. The only thing missing is adding it to the init.d or startup services.
    Also, it’s even easier getting start then what you said (at least on linux it is) as hudson supports packages: http://hudson-ci.org/debian/.

    sudo apt-get install hudson

    This downloads and installs hudson as a service that runs on startup.

  3. attosecond says:

    Just wanted you to know, your post inspired me to install and start using Hudson.. and now I can’t believe I got along without Hudson all these years!

    Thanks for the great post, and if you’re curious check out my followup

    http://sigtrap.wordpress.com/2010/05/01/saving-time-with-hudson-ci/

  4. Amit says:

    Installation procedure for Hudson, the open source Source code build management tool and If you want to create a build of specific svn revision, this link will help you lot… – See more at:
    http://www.ensarm.com/installation-procedure-source-code-build-management-tool-hudson/