The Scoop

Since I started using Ruby and Rails last year, I’ve come to know and like Capistrano, the deployment utility that makes pushing code and databases around a lot easier than it has to be. We use Capistrano for internal and external deploys at the Times, and it’s a pretty robust tool. While working on Fumblerooski and some other projects, I was looking for a Python-based deployment utility (although, to be fair, Capistrano can be used with just about anything), and I came upon Fabric.

If you haven’t heard of Capistrano, it and similar utilities save you the trouble of typing a series of commands to login to remote servers, update your code, bounce Apache, clean up files, etc. You put all that stuff into a single file that just runs those tasks when you need them. If you have an app that you’re regularly updating, it’s a godsend.

If you’ve used Capistrano before, Fabric is pretty similar in terms of its philosophy; there’s a fabfile in your project (like a capfile for Capistrano) that contains the configuration details and your commands for deploying code, restarting servers and the like. What I like about Fabric is that it makes virtually no assumptions about what you want to do. It doesn’t default to Subversion, or git, as a VCS. It doesn’t assume much of anything, which can be a little daunting if you’re used to a bit of code generation.

But that’s actually a good thing, because you end up writing fabfiles that only contain the stuff you need to have and nothing else. There’s a Django app that ties Fabric more tightly to Django’s manage.py utility, but I’m not sure I see the need for it. Without it, you type something like “fab deploy” instead of “python manage.py fab deploy”. But it’s there.

One thing I’d like to see from Fabric is better handling for sudo tasks on remote servers. This has been raised on the mailing list, and hopefully it gets resolved soon. Otherwise I’m really enjoying its simplicity and will use it for my Django apps going forward.