ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Got Project Automation?
Pages: 1, 2

Quick Release

A little while later, everyone on the team has checked in all of their code for the demo. Now you're ready to create a distribution file and deploy it to the demo server. But you only have a few minutes to spare before leaving for the big game and the release procedure involves the following tedious steps:

  1. Test the code in the mainline directory.
  2. Create a release branch in version control.
  3. Check out the contents of the release branch.
  4. Build and test the code in the release branch.

    (Fix any problems.)

  5. Package all of the files for the release into a distribution file.
  6. Test the contents of the distribution file.
  7. Tag the release branch in version control.
  8. Send the distribution file to QA.

And those are just the steps you can remember! Indeed, releasing your software used to be a time-consuming and error-prone process. Consequently, you didn't release new versions of your software very often. But you got tired of having to remember all of the steps in the release procedure and the stress of having to correctly type in all of the required commands. Now your project's step-by-step release procedure is automated (and even documented) with a pair of push-button release scripts.

The demo will take a bit of preparation, and you want a stable working area isolated from activity on the mainline. But you don't want to freeze the mainline and block everyone from starting on the next release. The solution is to create a release branch in your version control repository. The first script handles steps 1 to 4 of the release procedure, which you run with a version number:

  $ release_branch 2_7_1

The script runs successfully, telling you that the release branch was created and all of the code compiled and passed its tests. If there were problems, you would have made changes in the release branch directory, tested those changes, and committed the changes to the release branch. You might also have merged the changes onto the mainline by running another script.

Once you have a release branch, and you've fixed any problems, you're ready to actually generate a release. To do that, you run another script that handles steps 4 to 8, given a version number:

  $ release_generate 2_7_1

The result of running that script is a self-contained distribution file--the same file that a customer might install or deploy. You're almost there; only one more step left before you're outta here.

Dirty Deploy Details

Deploying the application to the demo server is another multi-step manual procedure that you're sure to do wrong, even if you weren't racing against the clock. But because your team deploys software frequently--and deploying it reliably and accurately every time is important--you've automated the deployment steps. All of the dirty deployment details are carried out for you when you run the deployment script:

  $ deploy

Behind the scenes, that script transfers the distribution file to the demo server and unpacks all of the deployment modules into their respective directories. But before the script actually fires up the application server, it has one more handy trick up its sleeve.

You wouldn't want to automatically deploy the application, only to have it fail to start because of a stupid configuration problem. Your application has a number of configuration values that need to be properly set before the application will start cleanly. So before starting the application server, the script runs a suite of diagnostic tests to quickly pinpoint any potential problems with the deployment.

Specifically, you've noticed that fouling up the database configuration is a common deployment mistake. You've lost too much of your hairline debugging that problem, so last week you wrote the following diagnostic test using JUnit:

  public class DiagnosticTests extends junit.framework.TestCase {

    public void testDatabaseConnection() {

      Database database = new Database();

      try {


      } catch(RuntimeException e) {
        fail("Unable to connect to the database '" +
             database.getURL() + "'. " +
             "Please check the 'database.url' property.");

Related Reading

JUnit Pocket Guide
By Kent Beck

The testDatabaseConnection() method attempts to connect to a database using an instance of the project's Database class. That class reads configurable values, such as the database.url property, from a configuration file. If the diagnostic test can't connect to the database, then it's likely that your application will suffer the same fate when it's run. Therefore, if the connect() method throws an exception when called by the diagnostic test, the fail() method is called to print out a helpful message intended to help you fix the problem.

Thankfully, the deployment script reports no problems. That tells you that the application was deployed, all of the diagnostic tests passed, and the application server was started. Your demo is live!

Tattletale Monitor

You click through a few pages of the web application as a quick sanity check. It looks great, but you'd like to sleep well tonight knowing that it will still look great for the suits driving the demo tomorrow. The project is on the line, and you've learned that bad things can happen to demos overnight.

Not to worry. You reach inside of your automation toolbox for a program that scrapes a web site every couple of minutes looking for bad words such as "Error" or "Exception." If any of those words show up, or the web site becomes unavailable, the monitor will send an SMS message to your cell phone. That way, if the application crashes, you'll have the maximum amount of time to fix it before the demo. Before you sprint to the door, you hook up the monitor to the demo site:

  $ monitor http://demoserver:8080/whizbang

Down at the tee-ball field, you watch your son step up to the plate. Meanwhile, back in the office, your faithful monitoring program is running unattended. Your cell phone is close by, but it never rings and you sleep like a baby because the demo goes off without a hitch.

Onward and Upward

The demo was so successful that customers are lining up at the door for copies of the application. Posting the distribution file on the company's public web site or burning it to multiple CDs would slow down your team, if it weren't for automation scripts that handle those tasks, too. And if someone happens to (ahem) report a bug, you can easily re-create the demo from version control. When the bug has been fixed, you can generate a new release at the press of a button.

Automation helped reduce the risk of a failed demo by notifying you early when problems occurred, wherever you were. Automation also saved you time and guaranteed consistent results by giving you repeatable ways to build and deploy your software. As you continue to prepare demos and release new software, this automation will pay for itself many times over.

Pragmatic Project Automation

Unfortunately, this story isn't the reality for most projects, maybe not even your project. Many teams try to do all these project chores by hand, but people just aren't as good at repetitive tasks as computers. Those teams risk running a procedure differently the one time it matters, on one machine but not another, or doing it just plain wrong. And frankly, you know you've got better things to do than run continuous builds, follow multi-step checklists, copy files around on servers, and monitor running programs. But how do you quickly and effectively pull all of these pieces together?

It may seem, from this article, that automating your current or next project involves a lot of work. Thankfully, you don't need to automate all of your project's procedures to start realizing the benefits of automation today. Each project chore you automate is an investment that pays off immediately and increases in value over time. You can quickly get started with each individual step by using freely available tools such as Ant, Maven, CruiseControl, JUnit, and simple scripts. The book Pragmatic Project Automation shows you how to put your computer to work doing your project's repetitive tasks the same way, time after time, without bothering you. That means you'll have more time and energy to do the really exciting--and challenging--stuff like writing quality code.

Mike Clark is a consultant, author, speaker, and programmer.

Return to the ONJava.com