I'm a perl addict and I try to do everything I can (within reason) to use my one hammer (perl) on every nail. That said, I think that a nice /bin/sh script is probably more portable than perl — at least in unix-like environments anyway.

Some things are just easier to do with a bourne shell. This appears to be an either/or situation where it doesn't matter if you use perl or bourne. ;-)

Regarding the test environment... If your test boxes don't change very much, you could just source an environment file with the appropriate #ifdefs to point to the correct binaries, directories, libs, etc. Once the environment variables are set up, you should be able to create any symbolic links you need.

Unless you're testing the extraction/build part of your application(s), I would recommend to extract a development or testing release from a version control system (e.g. subversion, clearcase) and perform the tests. That way, you can either correct any issues you find on the test box and check it back into the vcs or you can fix it on your development box, submit the fix to your vcs and extract the new code to your test box. Rinse, lather, repeat ;-)

You could automate the vcs extraction and testing rather easily (GUI testing is difficult to automate) by putting the process in cron or equivalent scheduler. I know of several big software firms that perform a variation of this.

Jason L. Froebe

Help find a cure for breast cancer! Net proceeds benefit the Susan G. Komen Breast Cancer Foundation and the National Philanthropic Trust. Help by donating - I'm walking 60 miles in 3 days in August 2007. (The day I return from TechWave is the first day of the Walk).

Blog, Tech Blog