I would argue that Puppet is also not suited to configuration management.

You can argue whatever you want, but Puppet's job is to enforce system state whereas Fabric simply allows programmatic use of SSH. Fabric and Puppet are completely separate projects with very different goals.

I've written loads of fabfiles and a subclass of Task a few times. I've also wrestled with Puppet and Chef and been resoundly defeated by both.

Fabric does what we need it to do for now for provisioning & deployment. And frankly you can make it do whatever you want. "Programmatic use of SSH" isn't something to be scoffed at; it's simple yes but it also lets you do whatever the hell you want very simply.

Yes, of course. Nothing is wrong with using Fabric. It's a clear step above trying to use shell scripts to manage your servers and deployments. But what I am seeing across several comments is that tools like Puppet and Chef are clearly misunderstood by many developers. As a sysadmin myself, I would say that there is definitely a larger picture to the use of Puppet/Chef than what developers are looking for, and thus something like Fabric is much more suitable.

I agree -- although I am sure you could write a system that manages config diffs, testing, backups and reporting in Fabric, it won't be pretty.

My current workflow for managing systems does use Fabric however. I maintain configuration using a custom framework and work under git/hg -- Fabric tarballs the tip, syncs the tarball to several dozen servers, and then runs and my configuration module on each server. I did use a bash script previously though.

Fabric looks like a competitor to Capistrano. However, the Capistrano model is fundamentally limited and unscalable. You really don't want developers to manage application deployment.

We are in the process of moving away from Capistrano to a system where code is automatically deployed when a new release is tagged. The deployment system is automatically managed with Puppet and everything is monitored with Nagios.