Our deployment process runs our migrations before the web code is deployed. This is satisfactory for 80% of what we need. In the cases where we'd want to migrate after the code change is deployed (removing a column), we'd need to split the work up into two separate deployments.
There are packages out there that help with this such as https://github.com/aspiredu/django-safemigrate/. It involves decorating the migrations with a member that indicates on what side of the deployment the migration should be run and change the post build script to run the package's version of migrate.
The main benefit of this is that we reduce how many deployments we make. And considering we tend to let our production releases build up (as of now), it seems like a good idea to protect ourselves in regards to deploying database schema changes.
Our deployment process runs our migrations before the web code is deployed. This is satisfactory for 80% of what we need. In the cases where we'd want to migrate after the code change is deployed (removing a column), we'd need to split the work up into two separate deployments.
There are packages out there that help with this such as https://github.com/aspiredu/django-safemigrate/. It involves decorating the migrations with a member that indicates on what side of the deployment the migration should be run and change the post build script to run the package's version of migrate.
The main benefit of this is that we reduce how many deployments we make. And considering we tend to let our production releases build up (as of now), it seems like a good idea to protect ourselves in regards to deploying database schema changes.