12 herbs & spices :: django & capistrano

Web operations have been described as the secret sauce of 2.0. It’s not an area that I deal with at work but I keep up to date with architectural decisions that impact web ops - especially around caching. I found Artur Bergman’s talk on the LiveJournal approach to architecture at Kiwi Foo both entertaining and informative. The LJ approach is being leveraged by many in both the Rails and Django community, with memcached, perbal or nginx being used as building blocks for scaling 2.0 operations. For more background on web operations/architecture check out the O’Reilly Radar Operations blog for more of Artur’s and others wisdom. O’Reilly are running a conference on the subject next year. High Scalability is another source of information on scalable web architecture.

With this in mind, when I was asked this weekend for some advice from a friend looking to put together a web play together I stressed the need for them to get the combo of a decent architecture, an ops machine in place before going crazy with feature development. Once this is in place they can get a minimal release up, then push out new functionality quickly and reliably - well at least from the web ops side of the equation. The less effort they have to focus on deployment and admin the more they can spend on developing the functionality that matters for their users.

So after dispensing this advice I thought that I should walk the talk myself and implement some of my own advice for this blog’s system. This blog was the typical ‘my first django project’. It was rapidly constructed around Christmas last year, porting existing content from the Rails based Typo system I had previously used.

I don’t make many changes to the code, arguably I don’t make that many changes/additions to the content either. However I’ve now placed the code under Subversion control and have installed Capistrano to automate admin tasks, specifically the deployment of new code onto my production server. Version control is mandatory for projects with more than one person working on them and highly desirable even if there is just one. For more information/explanation - should it be required - check out this visual guide to version control.

Simply put, Capistrano is a tool for automating tasks on one or more remote servers. It executes commands in parallel on all targeted machines, and provides a mechanism for rolling back changes across multiple machines. It is ideal for anyone doing any kind of system administration, either professionally or incidentally.

Capistrano is a Rails related tool. It’s primarily used for deployment but can be used to automate any set of tasks. And whilst it has come out of the Rails community and is written in Ruby it can be used in association with any language/web framework. Tasks to be automated are described in its own domain specific language (DSL) so there’s no requirement to learn Ruby. Capistrano is now at 2.1 and whilst there is a chapter on version 1.0 in the online Rails book there is little on 2.0, though improved 2.0 documentation can be expected. So here’s the sources I used to grok it for for deploying a non-Rails web application.

Prerequisites:

1. ssh and client certificates setup to provide password-less access to your production server from your workstation
2. knowledge of how your production environment works
3. a version control system, such as subversion setup and accessible from your production server

Timothee Peignier has written up the best description on how one can utilise Capistrano with Django. However I would qualify that by saying that you will get more, or get it quicker, if you first read up on Capistrano generally. Start with the minimal getting started doco, then read through the slides by Jamis Buck from the RailsConf. Test things out with some of the small examples. Understand how Capistrano is typically used with Rails, via the capify command that produces a Capfile and an associated config file. Find and read through the source (deploy.rb) for the Capistrano default tasks. Then read through Timothee’s post. You’ll almost certainly have to tweak the tasks to get things working for your own environment.

Unless you have a compelling reason to do otherwise I would go with the flow and use Capistrano’s method for organising releases. This approach lets you get the most from what Capistrano provides for free, with you only having to refine the tasks specific to your environment.

update:
Django added auto escaping of HTML in the version that I installed when putting Capistrano in place. I missed addressing that in the feed's templates.
Fixed now.