4 ms·

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 th

by rheide 14y ago

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?

emidln 14y ago
As part of your Procfile you could add --migrate to the syncdb that happens.
greghinch 14y ago
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.
codeinthehole 14y ago
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 https://github.com/tangentlabs/tangent-django-boilerplate If you look in the deploy function (https://github.com/tangentlabs/tangent-django-boilerplate/blob/master/fabfile.py#L123 https://github.com/tangentlabs/tangent-django-boilerplate/bl...), you can see the flow is something like: def deploy(): deploy_codebase() ... migrate() ... switch_symlink()
- rheide 14y ago
  This is a very creative solution. I like it.
wahnfrieden 14y ago
Push the migration separately before you push the updated model definitions, when you're adding fields.
webology 14y ago
Andrew Godwin wrote an interesting piece for the [Lanyrd blog](http://lanyrd.com/blog/2012/lanyrds-big-move/ 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.

by rheide 14y ago

emidln 14y ago

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

greghinch 14y ago

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.

codeinthehole 14y ago

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 https://github.com/tangentlabs/tangent-django-boilerplate If you look in the deploy function (https://github.com/tangentlabs/tangent-django-boilerplate/blob/master/fabfile.py#L123 https://github.com/tangentlabs/tangent-django-boilerplate/bl...), you can see the flow is something like: def deploy(): deploy_codebase() ... migrate() ... switch_symlink()

rheide 14y ago
This is a very creative solution. I like it.

wahnfrieden 14y ago

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

webology 14y ago

Andrew Godwin wrote an interesting piece for the [Lanyrd blog](http://lanyrd.com/blog/2012/lanyrds-big-move/ 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.