Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>"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.</p> <ul> <li>I don't use pip bundles, I install from a requirements.txt. I do run my own <a href="http://github.com/ask/chishop" rel="nofollow noreferrer">chishop</a> server with sdists of everything I need, so there aren't multiple single points of failure in the build process. I also use PIP_DOWNLOAD_CACHE on my development machines to speed up bootstrapping project environments, since most of my projects' requirements overlap quite a bit.</li> <li>I have <a href="http://fabfile.org" rel="nofollow noreferrer">Fabric</a> scripts that can automatically set up and configure nginx + Apache/mod_wsgi on an Ubuntu VPS, or configure the equivalent on <a href="http://webfaction.com" rel="nofollow noreferrer">Webfaction</a> shared hosting, and then deploy the project.</li> <li>I do not use --no-site-packages with virtualenv, because I prefer having slow-moving compiled packages (Python Imaging Library, psycopg2) installed at the system level; too slow and troublesome to do inside every virtualenv. I have not had trouble with polluted system site-packages, because I generally don't pollute it. And in any case, you can install a different version of something in the virtualenv and it will take precedence.</li> <li>Each project has its own virtualenv. I have some bash scripts (not <a href="http://www.doughellmann.com/projects/virtualenvwrapper/" rel="nofollow noreferrer">virtualenvwrapper</a>, though a lot of people use that and love it) that automate deploying the virtualenv for a given project to a known location and installing that project's requirements into it.</li> <li>The entire deployment process, from a bare Ubuntu server VPS or Webfaction shared hosting account to a running website, is scripted using Fabric.</li> <li>Fabric scripts are part of the project source tree, and I run them from a local development checkout.</li> <li>I have no need for SCons (that I am aware of).</li> </ul> <h2>Deployment</h2> <p>At the moment a fresh deployment is split into these steps:</p> <ul> <li><code>fab staging bootstrap</code> (server setup and initial code deploy)</li> <li><code>fab staging enable</code> (enable the Apache/nginx config for this site)</li> <li><code>fab staging reload_server</code> (reload Apache/nginx config).</li> </ul> <p>Those can of course be combined into a single command line <code>fab staging bootstrap enable reload_server</code>.</p> <p>Once these steps are done, updating the deployment with new code is just <code>fab staging deploy</code>.</p> <p>If I need to roll back an update, <code>fab staging rollback</code>. 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).</p> <h2>Examples</h2> <p>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 <a href="https://bitbucket.org/carljm/django-project-template" rel="nofollow noreferrer">https://bitbucket.org/carljm/django-project-template</a> - in <code>fabfile.py</code> in the repo root, and in the <code>deploy/</code> subdirectory.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload