Since AllPlayers kicked me out, I've had the chance to do the contractor thing for a little bit and it's been an interesting eye opener. AllPlayers was my first professional Drupal job and a fine example of a SaaS model at work! Best of all it sported what Drupal really could do running both a Drupal 6 install and Drupal 7 install that talked with one another.
But that was only the start. Through all the use of Ruby's Rakefiles, Composure, and Jenkins, I found that we did a lot of shell scripting still there. Where I'm at now, Promet Solutions, things are done a little differently. Since the company not only builds websites but supports what other people have built, it's not always easiest to drag out all the big SaaS components that I'm use to. Sometimes, you just have to go a little lower tech.
Enters Drush!
Yes we used Drush at AllPlayers. We did some pretty crazy things with it infact. One example was in our development environment build script, we had a beast of a one liner that took the current Drupal 7 administrative password and set the Drupal 6 administrative password to that. Took 3 devs to devise that "hack". No, I'm not talking about just the inert drush do this, drush do that. I'm talking about drush... "tell Drupal to get off it's ass and help me start something!" Hey lookdrush php-script to the rescue. Since the use of a new profile is out of the question, it is possible to build a "build script" using drush php-script to do your heavy lifting. One of those things I've been using it for recently is feeds. I've got about 8 csvs each with like 42,000 records in them with nodes, and I need to have those nodes to start off my environment. Needless to say, this environment needs to be able to be built on other servers too. So I make a shell script that does the following:
# some code to change file permissions
drush si --account-name=admin --account-pass=myKick@$$pass
drush en `cat mods_enable`
drush scr scripts/feeds_import.php
Every developer can use PHP that works in drupal. So these types of commands could be thrown into Rakefiles or what ever so that any dev can work on it and people can't use the excuse "It's Ruby!", though we all know a Rakefile is like child's play.
Note: In this example, you notice I don't have a drush make and do the mods_enable. That's a long story, but you could easily replace it with one. But to build the mods_enable, you just do something along the lines of:
drush pm-list --pipe --status=enabled --type=module > mods_enable
Pretty cool alternative with some noticeable shortcomings compared to a make file, but if you are going to store your modules in the repo, it makes for a simple easy thing to do.