You could also write a slightly longer but easier to maintain version if it ever grows or config details such as the server name change (I also fancy to think it's more "literate" when reading just the bit that does the work):
#!/bin/bash SERVER="ec2-54-235-210-62.compute-1.amazonaws.com" SSH_DJANGO="ssh -A django@$SERVER" SSH_ROOT="ssh root@$SERVER"
If the deploy scripts for your sites really are all the same, "generousfriends" could be fetched from the top-level directory name, too... and then this could become just one generic shell function deploy() in your laptop's .bashrc and not a separate file copy in each project folder. I bet the SERVER variable would fit nicely in .bashrc, too, as it could be reused in other little helper scripts and you wouldn't need to copy it around by value. But my approach adds a tiny little bit of "magic" to it (where did that "deploy" ran on the shell come from?), so if you want things to be completely straightforward, I see why you do it your way.
I write tons of these shell automation scripts and I agree that in many places configuration management tools are used they're a complete overkill and a solution in search of a problem (i.e. I would not choose to use them for fewer than a thousand VMs or hosts under management while I see them getting used for as few as a couple dozen VMs where they IMHO don't add real value). But maybe it lets current DevOps (web developers without a sysadmin available and with no sysadmin experience) write Ruby or Python instead of any bash at all, and that's what's so attractive about it, that sysadmin work just becomes another problem that can be solved with a web dev toolchain using a cool library that abstracts over all the boring and tricky shell commands. When all you have is a hammer...
Comment
Hi Peter,
You could also write a slightly longer but easier to maintain version if it ever grows or config details such as the server name change (I also fancy to think it's more "literate" when reading just the bit that does the work):
#!/bin/bash
SERVER="ec2-54-235-210-62.compute-1.amazonaws.com"
SSH_DJANGO="ssh -A django@$SERVER"
SSH_ROOT="ssh root@$SERVER"
$SSH_DJANGO ./upgrade_generousfriends.sh
$SSH_ROOT ./restart_generousfriends.sh
If the deploy scripts for your sites really are all the same, "generousfriends" could be fetched from the top-level directory name, too... and then this could become just one generic shell function deploy() in your laptop's .bashrc and not a separate file copy in each project folder. I bet the SERVER variable would fit nicely in .bashrc, too, as it could be reused in other little helper scripts and you wouldn't need to copy it around by value. But my approach adds a tiny little bit of "magic" to it (where did that "deploy" ran on the shell come from?), so if you want things to be completely straightforward, I see why you do it your way.
I write tons of these shell automation scripts and I agree that in many places configuration management tools are used they're a complete overkill and a solution in search of a problem (i.e. I would not choose to use them for fewer than a thousand VMs or hosts under management while I see them getting used for as few as a couple dozen VMs where they IMHO don't add real value). But maybe it lets current DevOps (web developers without a sysadmin available and with no sysadmin experience) write Ruby or Python instead of any bash at all, and that's what's so attractive about it, that sysadmin work just becomes another problem that can be solved with a web dev toolchain using a cool library that abstracts over all the boring and tricky shell commands. When all you have is a hammer...
Replies
I think you "get it". Keeping it simple is the way to go. And "literate" is an appropriate description.
The point is that it's a tiny executable README file basically. It's easy to understand and to maintain.