Think of them as shell-script frameworks. They include commonly used tasks/libraries that are useful for deployment and build tasks. Yes, you could use shell script, but these frameworks gives you a more convenient environment. They are also easier to set up and are more portable, since they have fewer external dependencies.
They are also easier to set up and are more portable, since they have fewer external dependencies.
Sorry, but WTF?
This made my toe-nails curl up.
You can't get a much easier setup than "already installed". You can't get much more portable than bash. And you can't get much less dependencies than zero.
Seriously, sit down and write the equivalent shell-script to whatever fabric/capistrano recipe you're currently using. I'm quite sure you'll be a bit baffled about why you bothered with them in first place.
To me it seems like Fabric/Capistrano were invented by people, for people, who are afraid to learn the bash syntax. This is unjustified, bash syntax is ugly but trivial.
Try getting a moderately complex shell script to run across different platforms. I dare you.
While it might be a safe bet these days to assume that bash exists (Though there are no guarantees), you can't really do anything with the shell alone - You have to call external commands, and they vary from platform to platform. FreeBSD has all sorts of annoying small variations of standard gnu utilities (or was it the other way around). And Windows doesn't even have a standard shell.
> To me it seems like Fabric/Capistrano were invented by people, for people, who are afraid to learn the bash syntax.
To me it seems like you never actually used shell script for anything serious.
Try getting a moderately complex shell script to run across different platforms. I dare you.
That's a broken premise. Your deployment script doesn't need (and should not) be complex by any metric. Your dependencies are ssh, tar, mv, cp, rsync/git/svn and a very small number of other utilities which are easily tested or wrapped for compatibility.
If you think you need more then you're likely doing it wrong (e.g. trying to reinvent version control and package management at the same time).
and they vary from platform to platform
That's the other broken premise. You don't "build once, run anywhere". You build platform specific modules and only trigger them centrally. Puppet shows the way.
To me it seems like you never actually used shell script for anything serious.
Hm, let me think, I've created and managed a deployment of >20 racks. But yeah, nothing serious.
> Your deployment script doesn't need (and should not) be complex by any metric.
I kind of agree, but complexity is a relative concept. mv and cp doesn't exist on Windows. And you really don't have to use exotic commands to run into compatibility issues between bsd and linux. It's not long ago I had an error reported due to the fact that readlink doesn't work equal on linux and bsd. I don't think readlink is in the "too complicated" basket.
> That's the other broken premise. You don't "build once, run anywhere".
Why would I prefer to write three different deployment scripts, if I could write one? Am I missing something here?
I kind of agree, but complexity is a relative concept. mv and cp doesn't exist on Windows. And you really don't have to use exotic commands to run into compatibility issues between bsd and linux.
Well, I have yet to see an application to span across Linux, BSD and wintendo at once. Such a setup obviously has much bigger problems than the deployment process ("broken beyond repair" comes to mind).
The real world deployments I have met were, at most, Linux/Solaris and even in these cases it was usually the cheapest to just scrap one (guess which) and move on. I have never seen a case where maintaining a mixed cluster could have possibly been worth the maintenance overhead.
Why would I prefer to write three different deployment scripts, if I could write one?
Because 3 simple scripts trump one that is gobbled up with conditionals.
I was with you up to this point, bash is not portable, and it is a hideous shell.
Any sane hacker writes all their scripts that are meant to be portable in standard bourne shell. Bourne is to bash as C is to C++. And people that put #!/bin/bash at the top of scripts that can be run by any bourne shell will burn in gnu/hell for the rest of eternity.
I was with you up to this point, bash is not portable
I have yet to encounter a system where bash wasn't available, so yes I'd say it's quite portable.
You are right, though, it would be more consequental to run with vanilla bourne shell.
and it is a hideous shell.
Well, that's a holy war I'm not so interested in. In my opinion all shells are quite horrible. The idea is to pick the lowest common denominator and bash just happens to be the most popular of the bunch. Your chances of finding a working /bin/bash on any given system are still orders of magnitude higher than finding a working capistrano/fabric along with the corresponding ruby/python toolchain.
But again, I agree that if you're forced to deal with esoteric platforms then your chances of finding a working bourne shell are even higher than that.
> I have yet to encounter a system where bash wasn't available, so yes I'd say it's quite portable.
Most systems (other than linux and OS X) do not include bash by default, and not everyone is able or willing to install it (and its dependencies) just to run a silly shell script. Sh one the other hand is almost as universal as ed(1), and implements the most sane subset of bash anyway.
Other systems (eg., Plan 9) don't have bash available at all (this is considered by some as a feature), while bourne is supported, if only for backwards compatibility.
> In my opinion all shells are quite horrible.
Most mainstream shells are indeed horrible (don't get me started on csh), but [there are some quite sane shells out there](http://rc.cat-v.org).
> The idea is to pick the lowest common denominator and bash just happens to be the most popular of the bunch.
lowest common denominator != most popular of the bunch.
> Your chances of finding a working /bin/bash on any given system are still orders of magnitude higher than finding a working capistrano/fabric along with the corresponding ruby/python toolchain.
And your chances of finding a working /bin/sh on any given system are still orders of magnitude higher than finding a working /bin/bash