1👍
As the documentation you quoted says, doing migrations in a transaction is a good idea. It’s such a good idea that Django does this by default with databases that support it.
But this only helps for the scope of one migration: if migration 0013
fails as in your example, the changes it introduces will be rolled back. The changes introduced by migrations 0011
and 0012
will not be reversed.
To reverse migrations 0011
and 0012
you’d have to roll back manually, e.g.
python manage.py migrate myapp 0010
But since your application will be running the previous release if your deployment fails, you can’t simply heroku run
that—Heroku doesn’t have the migration files for 0011
and 0012
.
This is likely, at least in part, why the Heroku documentation says
We suggest using
heroku run
, rather than the release phase, to make schema/data corrections.
If you remove your migration release phase command you could start deploying like so:
git push heroku main
heroku run python manage.py migrate
If the migration fails, simply reverse the last two migrations and then roll back to the previous release:
heroku run python manage.py migrate myapp 0010
heroku releases:rollback
As an extra precaution, consider putting your app into maintenance mode before you start your upgrade. This will prevent users from interacting with your site while it is potentially in an inconsistent state, e.g. after you deploy but before you apply your migrations.