Within a Django project with separate development and production branches sharing a common database, how do developers manage divergent database schema changes between branches to ensure smooth deployment and rollback procedures? Specifically, how do you handle situations where changes introduced in the development branch might potentially disrupt features or stability in the production branch, and what strategies or best practices do you employ to mitigate risks and maintain database integrity during deployment and rollback processes?
1 Like
I can’t speak for anyone else or any other group, but I can describe what we do.
Every developer is responsible for merging from master to their branch before merging their branch back into master.
We maintain a “staging” system where master gets deployed to, to test everything before it goes to production. Once it’s tested in staging, then a production deployment is schedule. Our production deployment process backs up the database, deploys the code, runs migrate and collectstatic, starts the system and runs a set of site tests.
I wrote a package that helps here a bit, django-linear-migrations: Introducing django-linear-migrations - Adam Johnson
Ensuring the smooth deployment of migrations will always be a tricky process. Some operations lock a whole table, so they’re fine at one scale and disastrous at another. I haven’t seen any great general solution there.