How do YOU deploy Django?

There are a good number of choices for deploying Django projects, whether they be Fabric, Chef, Puppet, Paver, or something else. However, each may be more suitable for some types of deployments than others. For example, Fabric's lack of parallel execution may leave you frustrated if you have many dozens of hosts to deploy to, and Chef's complexity and scattered documentation may be somewhat discouraging, as powerful as it seems.

Show and Tell

DUO Interactive have been using Fabric for their deployments. They've got a few projects in development and maintenance, most of which are single app server situations (which Fabric is awesome for). To keep our deployments consistent across our various projects, they wrote a smattering of management commands and Fabric methods, and tossed it up on GitHub as django-fabtastic. There is no real documentation aside from comments, but they figured they'd share what has worked for our simple deployments.
They've been extremely happy with Fabric and fabtastic for our simple deployments, but a new project looks to be moving towards the more complex end of the deployment spectrum in the future. they're looking at the possibility of at least five app servers by year's end, and are frustrated with our Fabric-based deployment (with a handful of app servers) for a few reasons:

• It can be pretty slow with a good number of app servers.
• Hosts are deployed to one at a time, with no abiiity to execute deployments in parallel.
• DUO Interactive sit their EC2 app servers behind one of AWS's Elastic Load Balancers. At any given time during deployment, users might get an updated app server, or one that has not been deployed to yet. This inconsistency is troubling. They'd still get this even with parallel execution (as it stands right now), but it would possibly be less of a problem.

For more information click here

In an Ideal deployment system

1. Fire off an individual deployment step to a large number of nodes at a time (in parallel, not one at a time).
2. Have the ability to wait until all nodes have completed certain steps before progressing onwards with the deployment. For example, wait until all nodes have checked out the latest version of the source before restarting the app servers. There would obviously still be a small period in time where not all nodes have reloaded the code, but it would potentially be a lot better than what we're seeing right now.