Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Create a nightly build system from scratch

Learn how to put together a sophisticated nightly build system in two days or less

By Dan Hansen, JavaWorld.com, 06/28/04

Let's suppose you have arrived at a new job site or landed a new contract. You may be a bit nervous, but not too much so; you have a reasonable level of confidence in your Java development skills. The first thing you do is try to get up and running. You read some of the documentation. You look at the hardware available for use. You check out the code from the source control system and run the Ant scripts to see how the current product looks as opposed to the project described in the (probably out-dated) schedule. Good.

Then you actually get into the thick of things. Somebody on the team wastes half your day by making a bad check-in, which you end up debugging since you must get your code compiling (you do want to get some work done, after all). Another morning comes and goes when somebody makes a late-night check-in to meet a deadline, and nobody notices that the build is broken until half the team checks out the broken build. Any seasoned developer has dealt with these types of issues in a variety of forms (and any seasoned developer has broken the build as well). How do you protect yourself and the team from forgetting to check in files, from producing code that only compiles on your development machine, or from instigating other frustrating and time-wasting behavior?

One tool in your arsenal is a continual build system. Continual build systems may go as far as to compile and run the unit tests every time you check in modifications. Regardless of how often you build, you always want at least a nightly build system. The benefits of such systems are well understood in the industry now—I know of no software development methodology that does not advocate a nightly build. As with other tools, it is no magic bullet, but it is part of the toolkit necessary to produce quality software.

At some point, you will ask management how builds and releases are handled. You may be surprised to discover that the builds are handled by hand on a release-by-release basis, which is common. There may even be a person (or entire department) devoted to producing software builds. In such a shop, each developer is usually on her own vis à vis building and testing daily. You can imagine (and probably have experienced) the problems that such systems can produce. So why don't you have a nightly build?

Invariably, everyone agrees that a nightly build system would be nice. But no time has been budgeted for such a snazzy tool—tools are a notorious waste of time for engineers. Weeks can be whittled away playing with the tool and slipping on the feature set. Management will not budget time for a build tool that requires weeks to create.

In this article, I show you how to put together a basic build system in a couple of days. It is just a matter of making some installs and plugging in your Ant scripts. We use the open source Web application Anthill; you will find its configuration to be only a small part of setting up such a system. So let's get to it.

Prerequisites

To start, I presume the following about your situation and your abilities: You are a reasonably savvy Java developer. You have worked on at least a couple of Java projects, and you not only know the language, but you also know a bit about Web applications and servlet containers. I am also going to presume that you know a bit about Ant and how to use Ant scripts. Finally, I'm going to presume that you have some understanding of source code control and have already put your code into such a system.