It's helpful to think of two separate processes: managing the server that will host your application(s) and deploying to the servers.
SSH + shell scripts are pretty good for one off things. But they're rarely idempotent. Chef and Puppet will say "you asked for nginx version x, you have it, so I won't bother installing it". You can also handle dependencies and roles, so you end up with things like "this hosts a Rails application, so you need Ruby and bundler, nginx configured a certain way, and the upstream load balancer needs to point to the new server". So using shell scripts ends up either taking longer or as you grow it gets more complex because you have to check for different things that a specialized tool just handles natively.
On the deploy side, ssh + shell scripts might be a better solution (IMHO stuff like Capistrano and Fabric can be seen as a fancy wrapper around that). So the procedure for a deploy might be "check out source, copy to a certain folder, create these symlinks, restart these daemons". Deploys, by their very nature, aren't idempotent, as each deploy is intended to change the state, you either finish it or abort and roll back.
I interviewed community managers from Puppet and Chef over at http://linuxadminshow.com, there are some interesting comments from both about the need for it even at small scale. Nathen from Opscode had a few comments about erchef. He also runs a podcast called "Food Fight" where they very recently talked about using Chef for the deploy process (http://foodfightshow.org/2013/01/application-deployment.html)
SSH + shell scripts are pretty good for one off things. But they're rarely idempotent. Chef and Puppet will say "you asked for nginx version x, you have it, so I won't bother installing it". You can also handle dependencies and roles, so you end up with things like "this hosts a Rails application, so you need Ruby and bundler, nginx configured a certain way, and the upstream load balancer needs to point to the new server". So using shell scripts ends up either taking longer or as you grow it gets more complex because you have to check for different things that a specialized tool just handles natively.
On the deploy side, ssh + shell scripts might be a better solution (IMHO stuff like Capistrano and Fabric can be seen as a fancy wrapper around that). So the procedure for a deploy might be "check out source, copy to a certain folder, create these symlinks, restart these daemons". Deploys, by their very nature, aren't idempotent, as each deploy is intended to change the state, you either finish it or abort and roll back.
I interviewed community managers from Puppet and Chef over at http://linuxadminshow.com, there are some interesting comments from both about the need for it even at small scale. Nathen from Opscode had a few comments about erchef. He also runs a podcast called "Food Fight" where they very recently talked about using Chef for the deploy process (http://foodfightshow.org/2013/01/application-deployment.html)