Today was scripting day. The aim was to throw together a quick-and-dirty shell script that would:
- pull the latest source out of CVS
- build and deploy it on a test box
- trigger a second Confluence server to start a suite of FatCow tests, confirming that the build did, indeed, work
- spam the Confluence developers with the results.
All in all, it turned out pretty well. It's a particularly nice feeling to be using your software to test itself: just a little more proof that you might indeed be working on something useful.
The unfortunate end-result, though, was that I ended up using three different scripting languages to accomplish this end -- four if you count the pre-existing Maven build system.
The bulk of the scripting was done in a bash shell-script. Then as I neared the end of the task, I found I needed to send an HTML MIME email message and found a quick Python recipe on the net that suited my purpose well. Then, when someone's mail client wasn't coping very well with multipart/mixed content, I had to munge all the results into a single document. For this sort of text processing, of course, Perl seemed the obvious choice.
I did try to go back to two languages by rewriting the mail stuff in Perl's MIME::Lite, but I stuffed something up in the process, and the mail was coming through with rather serious formatting problems.
All this is possibly a side-effect of having a casual acquaintance with several languages, rather than a deep and abiding relationship with one. If I were a Python guy, or a Perl guy, or even a dedicated shell guy, I would have been able to throw everything together in a single script, instead of mashing together my fragments of knowledge of each language.
I would have attempted to do it in one language if I could have used Ruby, but it wasn't installed on the server and I didn't want to install an entirely new language just to run one page of script.
One idea I had was to rewrite the whole thing in Groovy, but the idea scares me. I fear that if the scripts have access to Java libraries, they will begin to accrete dependencies until we need a build script to manage the build scripts.
As a long-time Perl guy with a little knowledge of other languages, sometimes the most effective route to a solution involves tying multiple scripts together. Sometimes the best solution isn't an all-in-one solution, it's the one that's made of four different puzzle pieces slotted together well enough to work. So fear not!
> One idea I had was to rewrite the whole thing in Groovy,
> but the idea scares me. I fear that if the scripts have
> access to Java libraries, they will begin to accrete
> dependencies until we need a build script to manage the
> build scripts.
So you're purposefully choosing a scripting language for its lack of interoperability. Interesting thought.
PS: The FatCow screen-shots look fantastic.
Did you consider Ant for Java...Even if you aren't building/compiling a Java app, Ant could still take care of all those things (CVS,compile,Mail,deploy) in a snap
PS:
Richard,
That sounds exactly like something a Perl developer would say ;) Tie a bunch of unrelated together with Perl, and make life a living hell for the guy who eventually replaces you.
"a web developer" - PLEASE read my RealNamesPlease policy if you're going to comment here.
The building and packaging is being done with Maven. The scripts are just glue to kick off everything else in the right order. (And frankly, "cvs co -P confluence" in a shell-script is a lot simpler than the equivalent ant task)
(Yes this is biased, I know)
I'm wondering why if you are already using Maven, you don't use maven to do these things?
1. maven scm:checkout-project
2. not always ideal, but maven appserver:install might get by (it has Orion support now)
3. writing a fatcow maven plugin based on cactus would allow you to reuse this test runner on other projects
4. now you're down to again
I would have thought this is about an equivalent amount of work to the scripting, and would be more reusable/maintainable.
Jelly is a downside though :)