I just came across
Pragmatic Project Automation, a book that both explains and justifies the rather aggressive build/release automation I do at work. I've taken this approach because I don't have *time* (or attention span) to do these repetitive jobs by hand, and really do believe that the based way to get something done the same way twice, reliably, is to have the computer do it... to the point that I have a "big-red-button" script that
- Checks out the current source tree in a reproducible way
- builds it into packages
- makes an install DVD from the packages
- loopback-mounts the ISO and exports it for net-install
- drives a keyAT serial-to-ps2 frob to reboot a machine and request that it PXE boot/install itself
- waits for it to come back up and runs the short version of our automated test harness
- summarizes the build failures
And as I write this I'm working on making it post the summary directly - I've been reading it an manually annotating it, but this gets it to other people's attention faster. Sound a little obsessive? (No, sounds a *lot* obsessive Yeah, yeah.) And I haven't even hooked in the KVM switch that'll let me take over the entire inventory of systems. What excites me about the book is primarily that it says "This is a good thing, and here's how to do more of it" - not that anyone's been dubious, of course - and secondarily that it comes up with *names* for the different aspects of what I'm doing already.
Now I just need to find someone else who takes it so completely to heart, is enthused about it, and has the skills to execute on it (ideally, advanced python fu, but *I've* only been doing python for 2 years, the reasoning and problem solving is much more important... ) and hire them. With the right associated skills, I could hire them immediately (because the open reqs are for other more specific needs) but for this alone, probably after the first of the year...