Hacker News Reader

Comment by rheide | Hacker News Reader

We've just started using South on Heroku, and one thing I've been confused by is that I have to deploy the code to the live server in order to be able to run the migration commands, thus causing the site to run on the new code that depends on the post-migration database structure for a short time.

Does anyone know an easy way to run the migration on a Heroku Postgres database without pushing the code to a live server?

View on HN

One way is to use symlinks to link in your live build. Then your deployment process can upload your new codebase and run the migrations before switching the symlink so that you new codebase is being served.

Where I work, we have a templated Django project that has a fabfile to do this: https://github.com/tangentlabs/tangent-django-boilerplate

If you look in the deploy function (https://github.com/tangentlabs/tangent-django-boilerplate/bl...), you can see the flow is something like:

    def deploy():
        deploy_codebase()
        ...
        migrate()
        ...
        switch_symlink()

This is a very creative solution. I like it.

Andrew Godwin wrote an interesting piece for the [Lanyrd blog](http://lanyrd.com/blog/2012/lanyrds-big-move/) where they talk a bit about putting their database in read-only mode. I know this doesn't cover your situation but it might help ease the transition of what to do while you are starting your migrations.

You should be able to get your database info by running

    heroku pg:credentials DATABASE_URL

And then you can just set it up as the database of a different install. Probably better to deploy the code before migrating though. Use maintenance mode to keep people out while you do.

As part of your Procfile you could add --migrate to the syncdb that happens.

Push the migration separately before you push the updated model definitions, when you're adding fields.

Reply on news.ycombinator.com