What are your settings, your tricks, and above all, your workflow?
These tools are great but there are still no best practices attached to their usage, so I don’t know what is the most efficient way to use them.
“Best practices” are very context-dependent, so I won’t claim my practices are best, just that they work for me. I work on mostly small sites, so no multiple-server deployments, CDNs etc. I do need to support Webfaction shared hosting deployment, as some clients need the cheapest hosting they can find. I do often have to deploy sites multiple times in different environments, so repeatable scripted deploys are critical.
At the moment a fresh deployment is split into these steps:
fab staging bootstrap(server setup and initial code deploy)
fab staging enable(enable the Apache/nginx config for this site)
fab staging reload_server(reload Apache/nginx config).
Those can of course be combined into a single command line
fab staging bootstrap enable reload_server.
Once these steps are done, updating the deployment with new code is just
fab staging deploy.
If I need to roll back an update,
fab staging rollback. Nothing particularly magical in the rollback; it just rolls back the code to the last-deployed version and migrates the database to the previous state (this does require recording some metadata about the migration state of the DB post-deploy, I just do that in a text file).
I haven’t used the Fabric scripts described in this answer for a few years, so they aren’t maintained at all and I disclaim responsibility for their quality 🙂 But you can see them at https://bitbucket.org/carljm/django-project-template – in
fabfile.py in the repo root, and in the
I use fabric to build and deploy my code and assume a system already set up for that. I think that a tool like puppet is more appropriate to automate the installation of things like apache and mysql, though I have yet to really include it in my workflow.
Also, I usually have a different virtualenv per project. They are created from a ‘base’ install of python where – as Carl pointed out – you can leave some global python libraries.
So in terms of workflow that would be: