Django, Whitenoise, and Heroku
tl;dr Heroku’s filesystem is ephemeral, so be careful when running the collectstatic command - it doesn’t necessarily do what you think it does..
Our current production asset delivery setup looks like this:
- Run grunt locally to generate static files
- Commit changes to repo
- Push to Heroku
- Run
collectstaticto . . .
Continuous delivery at YunoJuno
BitBucket to Codeship to Heroku
Disclaimer: I'm a Continuous Deployment sceptic. I've always been suspicious of people who automatically deploy code to their live environment, and still am. Seems risky to me. See this article for more details on the difference between continuous delivery and deployment.
I've blogged before about our deployment tools, . . .
Heroku app aliases
Using git remotes to alias your apps
We have four permanent Heroku apps running in production (our live site, our staging site, a development site and a demo) as well as various ephemeral apps that get created for long-running branches. Running Heroku CLI commands can become a bit of a pain in scenarios like this as you have to append the app name as an option:
# this will . . .Infrastructure as a disposable service
Hot-swapping infrastructure services on-the-fly.
Earlier this week we had what could have been a catastrophic infrastructure failure - our ElasticSearch cluster went offline. Given that this powers the core functional element of our entire business, this was not a good thing to wake up to.
As I started investigating what had gone wrong, I could practically hear the sniggers from . . .
Deploying Django apps to Heroku (#3)
In the third (probably not final) post on our deployment process, our Fabric
script has become intelligent enough to manage deployment options on our
behalf.
First a quick recap. As I've posted previously, YunoJuno is a Django app,
hosted on Heroku. We use Fabric to manage deployments, which, as is the
Heroku way, . . .
Turbo deployments with Heroku 'Preboot'
Heroku's deployment model has always had a single point of frustration - the requirement to take the site offline, if only for a couple of minutes. In certain circumstances this is solved by the 'preboot' labs feature.
I love Heroku's simple git deployment model, and having lived with it for almost a year, I can't . . .
Managing multiple Heroku configurations
Using Fabric and Git to manage Heroku environment configuration.
As previously discussed YunoJuno runs on Heroku. Doing so means adopting
their 12-Factor App philosophy, which has worked out great for us, and makes the project very clean in terms of separating code from configuration. One of its core tenets (and a requirement for hosting apps on Heroku) is the use of environment variables to store . . .