For about eighteen months, between late 2010 and early 2012, I maintained a blog at this address.
Busy with a new job, and with my attention supplanted by social media, I stopped writing. My site sat, neglected as time passed. Two years later during a server rebuild, I threw a placeholder page up with the intent of creating a new website.
Presented at PyCon AU, Brisbane, on August 3, 2015
The power and flexibility of Django comes with drawbacks. One of the toughest for project management is working out how to deploy your Django application. If you ask five different authorities on how you should do it, you’ll get six different answers.
And if someone says “Just use fabric!”: they’re not helping.
Release management, dependency wrangling, virtualenv care and feeding; to .whl or .deb? To containerize or Heroku-ize? Do you really have to allow your servers unconstrained Internet access just to build your virtualenv?
As a Django user, you might end up writing more deployment solutions than Django projects. I know I have.
There’s no one true way of doing Django deployments, but some work better than others. Maybe I can show you.