Hi mates, i am working with my team ( we are 4 in total) on a django project and any developer could make a modification on a model and then generate his migrations but sometimes it is really difficult to deploy the app after merge (even for tests), some reasons are : XXX_migration_XXX has been applied before his dependency XXX_migration_XXX, this is because of inconsistency between the differents Databases and the different migrations.
So i started to think that to avoid this kind of situation we should stop versionning the migrations. What do you think ? Did you sometimes fall in this kind a mess with migrations, (spaghetti migrations ;-) )?
PS : Sorry about my english
Top comments (7)
I have run into this problem in the past and one strategy we have used is reset the migrations after each release. It has helped us keep the migration folder small, and it's bit easier to see the conflicting changes. I do think during development cycles if you isolate your applications and models per developer you eliminate almost entirely the conflicts from migrations if combined with a reset after release.
Your issue is communication, not source control :-) You should probably consider using another branching strategy and if a feature requires changing the DB you should communicate it to the others, especially because you're 4, not 45.
This is a good guide on how to manage conflicts: algotech.solutions/blog/python/dja...
You can merge migrations or just squash them to a single file.
You obviously need the migrations in the source control, otherwise you won't be able to reproduce the schema from start or to create the next migration building on the previous one.
In the framework me and my team are using, we use 1 migration = 1 table strategy.
Every time we pull a modified migration, we just run a script to automatically re-import and repopulate the database. Hope this helps.
Care to explain why?
like in my case.