Automation Stories

[Dirk Schreckmann]

Over in the "Welcome Mike Clark!" thread, Mike asked:

"What types of automation are you using on your project and how is it helping you?"

After reading Pragmatic Project Automation, one of the first things I did was set up something to monitor a web and ftp server I've had go down twice over the past year. The monitor is setup to send a text message to my cell phone if something goes down. No messages, yet, and it's not something I worry about manually monitoring anymore.

What else have folks been automating?
[ September 20, 2004: Message edited by: Dirk Schreckmann ]

[Jeanne Boyarsky]

We do the typical Ant build thing. We use Ant for project level builds to compile, run unit tests and create distributable jars. We also use Ant to build a full application each night (not continuously yet though.)

We also use Ant to make a copy of our configuration files for each deployment environment and update the properties for environment specific settings. That way all the environment differences are in one file.

Dirk, that's a good use!

[Mike Clark]

Originally posted by Jeanne Boyarsky:
We also use Ant to make a copy of our configuration files for each deployment environment and update the properties for environment specific settings. That way all the environment differences are in one file.

Are you using a <filterset> to replace tokens in a master configuration file as it's copied?

[Bear Bibeault]

I use Ant in much the way Jeanne described, and yes, when copying files I frequently 'customize' them using filtersets.

[Gian Franco]

Hi,

I started using Ant with original intent to decouple
the dependency of projects as much as I could from
proprietary IDE's. We started with JBuilder, then
Eclipse and it's big brother WSAD.

All these IDE's have fancy features, but different
users have different preferences which might in
crucial times influence the deployment of the
software. A solution to avoid complications when
time is little and stress is high, was to write
an Ant script that does at least compilation and
packaging. This script is used by everybody and
it's independent from local settings or references
to libraries.

I know there are fancier uses for this project
automation tool, but for now this is good enough.

Next to Ant we've developed a simple but effective
naming scheme for our versioning in CVS, again this
suits the use we make of it. The naming scheme is
coupled with another lightweight task administration
tool (in Excel this time) where all tasks are given
a code-name, a place on the file system (for documentation),
a status (open, to_develop, to_test, closed etc.)

The task code-names are taken over in our monthly
hours administration system.

In a nutshell that's how the whole thing looks like
right now. The development proces and related tasks
are supported pretty well by this set of tools, the
thing that might need some polishing is linking the
separate parts togheter.

Cheers,

Gian Franco Casula

[Daniel Mayer]

We are using a combination of Ant, Cruise Control and shell scripts to

- have a continuous build running,
- have nightly distribution builds, and
- have a webstart distribution deployed to our intranet every night.

We also make heavy use of Eclipses Ant Builder to automatically recreate generated sources when the definition files change - for example when using JAXB to generate code from XML Schema.

Recently I started to automatically update the screenshots for the online handbook of one of our projects, using the Ant tasks of http://www.jdemo.de/

[Ernest Friedman-Hill]

I wish I had a unique automation story to tell, but instead I'll have to content myself with "me, too." My two major projects each use shell-script/Makefile-driven continuous integration (these setups have been running since before Ant and CruiseControl existed: they're both very long-running projects!) We run continuous builds and unit tests, and each night we run our full application tests (about 3 hours worth on one project) as well as metrics and coverage tests (using EMMA, which is a really nice package, along with some more shell scripts.)

It's really great to have the kind of project knowledge that a setup like this gives you. You always know what state things are in, and if you make a mess, you know about it quickly!

[Mani Ram]

Originally posted by Dirk Schreckmann:

What else have folks been automating?

I have written a tool that automates my timesheet entry

[Lasse Koskela]

Originally posted by Mani Ram:
I have written a tool that automates my timesheet entry

I guess you're not working overtime, then?

[Craig Demyanovich]

At my place we use qmail in place of sendmail. qmail queues were regularly growing exceedingly large, so large that long delays in delivery were occurring. One thing that I did to address this problem was to write a program to check the queue on each machine and send an alert (via cell phone and/or email) if the number of messages in it exceeded a threshhold. My manager scheduled this program in cron, and he has been thankful since then for being relieved of this tedious and repetitive task. I wrote the program in Java and integrated with TelAlert to do the notifications, as we had already done something similar for an EDI monitor.

Craig

[Ted Young]

We've automated our builds with Ant and Anthill (Open Source) -- thought we'll be switching to another "build panel" that has better support for ClearCase.

Right now the Ant build file:

Updates the view (i.e., makes sure that the local copy has the latest files)

Checks-out one of the files and replaces a token with the build and version number (which ends up in the title bar of the application and in the Help...About dialog)

Compiles everything

Builds an application JAR

Does an "Undo" checkout on the file which was token-replaced (we don't need to keep a copy of it)

Moves the application JAR with the rest of the JARs into a lib directory

Copies the config file appropriate for usage (QA or Production/release) into the config directory

Runs the unit tests and generate a report available on an internal web site

Builds a RAR (zip-like) file containing the app JAR and all other JARs and config files.

Converts the RAR to a self-extracting unrar (decompressor) file

Sends out email indicating whether the whole process passed or failed, and if passed, indicates where the self-extracting file is.

The best thing about this is that it eliminates the manual steps that used to cause problems when we dropped to QA and forgot a file, or forgot to set the config to point to QA instead of development, etc. During the calm time periods, I automated as much as possible so that under stress (need to release an urgent bug fix), I just click one button to build knowing that everything (should!) works.

;ted

[Mike Clark]

Originally posted by Mani Ram:
I have written a tool that automates my timesheet entry

That reminds me of a funny automation story somebody told me. It seems their company was having an internal auction, and this person really wanted a few things. So he used Excel macros with a bit o' automation to track the highest bids on items he wanted and place his bid right before the time expired on the auction.

And he got all the items he wanted! But the second time they had an auction, he didn't get anything. He suspects it was because he shared his automation scripts with another person in the company. :-)

Mike

[friso dejonge]

we are doing the same sort of automation:
For several project we have cruisecontrol with ant, (hourly builds and nightly builds) The nightly builds do the extensive tasks like full dbunit, junit, javadoc and checkstyle as well as publishing the results
The hourly build just checks out of pvcs, builds, emails results, ear's up, distributes to right location. (I build a deploy, but had to take it out since I was deploying on a server I was not allowed access to - guess it took over someones daily job !!)