Make your builds always available
When you are working on a software project, often you have other people who need to access the builds. For example, here at Sun when I work with the JAXB RI, our builds need to be handed to the quality assurance team, the TCK team, the JAX-RPC RI team, and other miscellaneous people who use the JAXB RI internally.
For many of them, this hand-off of a build is not just one time thing. It is a continuous on-going process. For example, the QA team needs a new build once we fix a bug they reported. During the lifetime of a project, this cycle happens a lot.
For this reason, it is often convenient to have a standard distribution channel of your builds, where people can always get the latest build. It is even better if thereâ€™s a permanent link to the latest build, because often other teams have their own procedure of integrating a build (such as putting that into their CVS repository), and a static URL allows automation of this process.
It is also better to have fresher builds. Our time is always more valuable than machinesâ€™ time, so itâ€™s better to spend CPUs to start a new build now than to ask for the QA team to wait another day for tonightâ€™s nightly build.
An added benefit of doing a constant build is that you can get notified when the workspace doesnâ€™t build. I often forget to put back a file or two, and as a result the build breaks, and I know itâ€™s not just me.
Hence comes the notion of â€œcontinuous buildâ€, where a program automatically builds a new version of your build every time someone changes something in the repository. I found an tool called Damage Control that makes this easy, but unfortunately I found that it doesnâ€™t scale to the size of the projects that I work with.
Therefore, I decided to re-implement it on my own, by using Java. Iâ€™m calling it Hudson, because in a sense this system is like a build master in my project, and Hudson sounded like just that kind of a name.
Anyway, Hudson is a web application, and the installation is as simple as dropping a war file into a web container, such as Tomcat. Everything else can be configured through the web interface.
A typical set up in Hudson is to set up a CVS changelog trigger, so that change notification e-mail from CVS will automatically start a new build. Hudson then starts a new build, assigning a unique build number, recording the build log, and archiving the results. It has an RSS feed so that people can be notified of new builds or build failures. It has a log rotation so that the history information wonâ€™t get too big.
Hudson can also be used to monitor jobs that run externally. I have many cron jobs, and I hook them all up to Hudson, Hudson records the output from a job, keeps history of past runs, and produce RSS feeds. Once I see a failure, I can go to Hudson, browse all the outputs I need to see, and find out when it started to fail. I found this to be a lot easier than going through e-mails from cron.
So, try Hudson! I hope youâ€™ll like it.
(A part of Hudson, in particular the art work, is covered by the license of Damage Control)