problem: when deploying new database migrations, after the database gets migrated, we might still be running the previous version of the code (pre-migration) and that can lead to exceptions/failures as the old code encounters columns (or doesn't find columns) that it expects. we've seen this happen a few times.
this only happens when pushing new deploys with backwards incompatible db migrations, so it's relatively rare. but worth thinking about in the long term.
problem: when deploying new database migrations, after the database gets migrated, we might still be running the previous version of the code (pre-migration) and that can lead to exceptions/failures as the old code encounters columns (or doesn't find columns) that it expects. we've seen this happen a few times.
this only happens when pushing new deploys with backwards incompatible db migrations, so it's relatively rare. but worth thinking about in the long term.
found some good articles about this:
https://cheigh.me/blog/posts/2022-05-10-enforcing-zero-downtime-django-migrations.html (describes the problem well but no clear solution) https://github.com/3YOURMIND/django-migration-linter?tab=readme-ov-file interesting tool..?
https://forum.djangoproject.com/t/lets-talk-zero-downtime-migrations/28388/5 (very recent discussion of this)
https://fly.io/django-beats/smooth-database-changes-in-blue-green-deployments/ (somewhat very complicated..?)
also render's docs re zero downtime deploys