Probleme bei der Versionierung von Migrationen

Bei Arbeiten im Team bzw. bei einem Workflow mit sogenannten Feature-Branches mit einem Versionierungsystem wie git kommt es immer wieder zu Problemen mit den Migrationen, die von Django erstellt werden. Wenn zum Beispiel in einem Feature-Branch die Datenbank durch eine Migrationen verändert wurde, ist diese Veränderung nicht in einem anderen Branch, zum Beispiel dem Main-Branch verfügbar.

Ähnliche Probleme ergeben sich, wenn zwei Personen an der gleichen App arbeiten und Model-Felder ändern. Dann kann es plötzlich zwei Migrationsdateien mit dem Präfix 0002 haben.

Was kann man dagegen tun?

Das Problem ist nicht neu und nicht trivial. Es gibt keine gute Lösung dafür, nur ein paar Regeln, wie man mit dem Problem umgeht.

Vermeidet, gleichzeitig an einer App zu arbeiten

oder zumindest sollte nur einer von den Beteiligten Änderungen am Model vornehmen.

Umbennen der Migrationsdateien

Falls doch mal zwei Migrationsdateien mit dem selben numerischen Präfix im Code landen, kann umbenannt werden. Das Dependencies-Attribut nicht vergessen, anzupassen.

Migration Rollback

Falls man in den wichtigen Main-Branch wechselt (checkout), könnte man auf dem Feature-Branch einen Rollback der Migration machen. Das geht in Django relativ einfach, in dem man einfach die Nummer der Migration bei migrate angibt.

python manage.py migrate events 0001

Hier migrieren wir gezielt die Migration 0001, die Datenbank wird daraufhin in den Zustand zurückgesetzt. Jetzt könnte man in den Main-branch wechseln, und dort mit dem Zustand der Datenbank wie vorher, weiterarbeiten.

Branch Datenbanken

Falls im Feature-Branch Arbeiten anstehen, die das Datenbank-Schema massiv verändern und vieleicht sogar Daten-Migrationen durchgeführt werden müssen, ist es zu überlgen, ob man nicht eine eigene Datenbank im Feature-Branch anlegt. Mehr zu dem Thema hier: http://ses4j.github.io/2019/05/31/django-maintaining-database-per-branch-git-hook/