Ryan's Blog

Build Automation - Too Easy to Pass Up

This week I setup continuous builds and manual click-to-build sort of process using Luntbuild and Ant.  I was really surprised at how easy it is to  use and maintain.  Then I began wondering why these automated build systems aren't more popular.  Most places that I have worked at did not have automated, "too easy to mess up" sort of builds.  I think that it might be the perception of the tool.  Maybe people think it is much harder to get up and running than it actually is?  Below is information on what I did.

Luntbuild Conceptually

Luntbuild (http://luntbuild.javaforge.com/) is build automation software that is open source.  Through Luntbuild you can setup continuous builds (i.e. build every 5 minutes if there is new code checked in), manual builds (click a button and it creates an EAR) and most things that are related to creating that build.  Luntbuild is a Java based application that can be deployed on a normal application server and can communicate with many different source control systems.  Many of the details that would otherwise be manual process or messy Ant tasks like checking code out of repositories, is handled by the software.

The Setup

Luntbuild handles all of the previously manual process that was in place before.  I have it configured to pull the code from the repository (Subversion in my case).  For this particular scenario, it was reading from a branch.  It can determine if there were any updates to the repository since the last time it built and then decide to run or not based on that.  Next it compiles the source.  This is the one part that I had to do any real work.  Here I needed to create a minimal Ant build file that would compile the files and move the configuration files and libraries that the application needed etc.  In Luntbuild I can define variables such as build number and location of files etc that are passed into the executing Ant script and used in the build file I'm creating.  Then in Luntbuild I would specify where the build file was stored in the repository.  What is important to note here is that I didn't upload the build file.  It's stored in the repository just like everything else.  This is good for several reasons.  A big reason is that it will also allow me to build locally with the same Ant build file as is being used on the Luntbuild server.  Another is that it will automatically get updated whenever a new build script is checked in, automatically.  Once I have specified the build file, it's time to set up a schedule.  I had two kinds of builds.  One for continuous integration and another for release builds.  For the CI build I had it check every 5 minutes for new code and build if it is there.  As a part of both builds, version numbers have been set up.  So I set the initial version number to 1.0.0.  For each CI build or release build, that build number is automatically incremented.  The release build was not made to be executed automatically, but when there is a release.  This is not something that is known until some new feature is implemented or something similar.  In that case, the developer would log in to Luntbuild and after a couple of clicks, would start the build process.  It's important to note that this build is the exact same as the CI build, the only difference is the schedule and the configuration options of the build.  Part of that configuration is tagging.  For release builds, I wanted the ability to recompile that build at anytime.  To do this I just pointed Luntbuild to the proper tags directory, configured it to enable tagging and it automatically creates a tag with the proper version number as its name whenever the release build succeeds.

End Result

The end result here is saving a ton of time.  For releases, with just a couple of clicks, the software will pull down the latest code, compile it, tag it and put it on the site for easy download.  The benefits of Continuous Integration are great as well.  Things like automated tests, style checking, complexity checking can be integrated in relatively easy.  In my usage of this, we're still working towards style checking, automated unit testing etc, but a lot of benefits can still be gained from this minimal usage of Luntbuild.  So that brings me back to my question.  Why aren't more people using automated build software like Luntbuild?  I was new to Luntbuild and far from an Ant expert and I was able to get the whole project automated and building in probably about a day.  Probably the biggest time consumer of getting automated builds in an organization is the political time.  Sometimes it can be difficult to change a release process, even if it is more efficient.  People are often resistant to it and it is necessary to "sell the idea".  It also requires an application server that can be used for the builds.  To get that space on a server, it may require selling to even more people.  That said, automated build software setup is definitely time well spent on any project.

Posted at 08:24AM Oct 15, 2007 by Ryan Senior in Programming  |  Comments[0]