Czy powinienem dodawać pliki migracji Django do pliku .gitignore?

Czy powinienem dodawać pliki migracji Django do .gitignorepliku?

Ostatnio dostałem wiele problemów z git z powodu konfliktów migracji i zastanawiałem się, czy powinienem oznaczać pliki migracji jako ignorowane.

Jeśli tak, jak mam dodać wszystkie migracje, które mam w moich aplikacjach, i dodać je do .gitignorepliku?

Cytat z dokumentacji migracji Django :

Pliki migracji dla każdej aplikacji znajdują się w katalogu „migrations” wewnątrz tej aplikacji i są zaprojektowane tak, aby były zatwierdzane i rozpowszechniane jako część jej kodu źródłowego. Powinieneś zrobić je raz na swojej maszynie deweloperskiej, a następnie uruchomić te same migracje na maszynach swoich kolegów, maszynach pomostowych, a ostatecznie na maszynach produkcyjnych.

Jeśli zastosujesz się do tego procesu, nie powinieneś dostawać żadnych konfliktów scalania w plikach migracji.

Podczas scalania gałęzi kontroli wersji nadal możesz napotkać sytuację, w której masz wiele migracji opartych na tej samej migracji nadrzędnej, np. Jeśli do różnych programistów wprowadzono migrację jednocześnie. Jednym ze sposobów rozwiązania tej sytuacji jest wprowadzenie _merge_migration_. Często można to zrobić automatycznie za pomocą polecenia

./manage.py makemigrations --merge

która wprowadzi nową migrację, która zależy od wszystkich obecnych migracji głowy. Oczywiście działa to tylko wtedy, gdy nie ma konfliktu między migracjami głów, w takim przypadku będziesz musiał rozwiązać problem ręcznie.

Biorąc pod uwagę, że niektórzy tutaj sugerowali, że nie powinieneś przenosić migracji do kontroli wersji, chciałbym rozwinąć powody, dla których powinieneś to zrobić.

Najpierw potrzebny jest zapis migracji zastosowanych w systemach produkcyjnych. Jeśli wdrażasz zmiany w środowisku produkcyjnym i chcesz przeprowadzić migrację bazy danych, potrzebujesz opisu bieżącego stanu. Możesz utworzyć oddzielną kopię zapasową migracji zastosowanych do każdej produkcyjnej bazy danych, ale wydaje się to niepotrzebnie uciążliwe.

Po drugie, migracje często zawierają niestandardowy, odręczny kod. Nie zawsze można je automatycznie wygenerować za pomocą ./manage.py makemigrations.

Po trzecie, migracje powinny zostać uwzględnione w przeglądzie kodu. Są to znaczące zmiany w systemie produkcyjnym i jest wiele rzeczy, które mogą się z nimi nie udać.

Krótko mówiąc, jeśli zależy Ci na danych produkcyjnych, sprawdź migracje do kontroli wersji.

Możesz wykonać poniższy proces.

Możesz biec makemigrations lokalnie, co spowoduje utworzenie pliku migracji. Zatwierdź ten nowy plik migracji w repozytorium.

Moim zdaniem nie powinieneś w ogóle biegać makemigrationsw produkcji. Możesz biecmigrate w środowisku produkcyjnym, a zobaczysz, że migracje są stosowane z pliku migracji, który został zatwierdzony z lokalnego. W ten sposób unikniesz wszelkich konfliktów.

W LOKALNYM ENV , aby utworzyć pliki migracyjne,

python manage.py makemigrations 
python manage.py migrate

Teraz zatwierdź te nowo utworzone pliki, coś jak poniżej.

git add app/migrations/...
git commit -m 'add migration files' app/migrations/...

W ŚRODOWISKU PRODUKCYJNYM uruchom tylko poniższe polecenie.

python manage.py migrate

Cytat z dokumentacji 2018, Django 2.0. (dwie osobne komendy = makemigrationsi migrate)

Powodem, dla którego istnieją oddzielne polecenia do wykonywania i stosowania migracji, jest to, że zatwierdzasz migracje do systemu kontroli wersji i wysyłasz je z aplikacją; nie tylko ułatwiają programowanie, ale także mogą być używane przez innych programistów oraz w środowisku produkcyjnym.

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

TL; DR: zatwierdzaj migracje, rozwiązuj konflikty migracji, dostosuj przepływ pracy git.

Wydaje się, że musisz dostosować przepływ pracy git , zamiast ignorować konflikty.

W idealnym przypadku każda nowa funkcja jest opracowywana w innej gałęzi i łączona z powrotem z żądaniem ściągnięcia .

Nie można łączyć PR, jeśli występuje konflikt, dlatego kto musi scalić swoją funkcję, musi rozwiązać konflikt, w tym migracje. Może to wymagać koordynacji między różnymi zespołami.

Ważne jest jednak, aby zatwierdzić pliki migracyjne! Jeśli pojawi się konflikt, Django może nawet pomóc ci rozwiązać te konflikty ;)

Nie mogę sobie wyobrazić, dlaczego masz konflikty, chyba że w jakiś sposób edytujesz migracje? Zwykle kończy się to źle - jeśli ktoś przegapi jakieś pośrednie zatwierdzenia, nie będzie aktualizował z poprawnej wersji, a jego kopia bazy danych zostanie uszkodzona.

Proces, który śledzę, jest dość prosty - za każdym razem, gdy zmieniasz modele aplikacji, wykonujesz również migrację, a następnie ta migracja się nie zmienia - jeśli potrzebujesz czegoś innego w modelu, zmieniasz model i zatwierdzasz nowa migracja wraz ze zmianami.

W projektach typu greenfield często można usunąć migracje i zacząć od nowa z migracją 0001_ po wydaniu, ale jeśli masz kod produkcyjny, nie możesz (chociaż możesz zmiażdżyć migracje do jednego).

Zwykle stosowane rozwiązanie polega na tym, że zanim cokolwiek zostanie scalone w master, programista musi pobrać zdalne zmiany. Jeśli występuje konflikt w wersjach migracyjnych, powinien zmienić nazwę swojego lokalnego migracji (zdalna była prowadzona przez innych programistów i potencjalnie w produkcji) na N + 1.

Podczas programowania może być w porządku po prostu niezatwierdzanie migracji (jednak nie dodawaj ignorowania, po prostu nie rób tego add). Ale po rozpoczęciu produkcji będziesz ich potrzebować, aby zachować synchronizację schematu ze zmianami modelu.

Następnie musisz edytować plik i zmienić dependenciesna najnowszą wersję zdalną.

Działa to w przypadku migracji Django, a także innych podobnych aplikacji (sqlalchemy + alembic, RoR itp.).

Posiadanie wielu plików migracyjnych w git jest kłopotliwe. W folderze migracji jest tylko jeden plik, którego nie należy ignorować. Ten plik to plik init .py, jeśli go zignorujesz, Python nie będzie już szukał podmodułów w katalogu, więc wszelkie próby zaimportowania modułów zakończą się niepowodzeniem. Zatem pytanie powinno brzmieć, jak zignorować wszystkie pliki migracji oprócz inicjalizacji .py? Rozwiązanie jest następujące: dodaj „0 * .py” do plików .gitignore i to doskonale spełnia swoje zadanie.

Mam nadzieję, że to komuś pomoże.

Gitignore migracje, jeśli masz oddzielne bazy danych dla środowiska programistycznego, przejściowego i produkcyjnego. Dla dev. cele Możesz używać lokalnej bazy danych sqlite i bawić się migracjami lokalnie. Poleciłbym stworzyć cztery dodatkowe oddziały:

1. Mistrz - czysty nowy kod bez migracji. Nikt nie jest powiązany z tą gałęzią. Używany tylko do przeglądu kodu

2. Rozwój - codzienny rozwój. Zaakceptowano push / pull. Każdy programista pracuje nad sqlite DB

3. Cloud_DEV_env - zdalne środowisko chmurowe / serwerowe DEV. Tylko ciągnąć. Przechowuj migracje lokalnie na komputerze, który jest używany do wdrażania kodu i zdalnych migracji Dev bazy danych

4. Cloud_STAG_env - zdalne środowisko chmury / serwera STAG. Tylko ciągnąć. Przechowuj migracje lokalnie na komputerze, który jest używany do wdrażania kodu i zdalnych migracji bazy danych Stag

5. Cloud_PROD_env - zdalne środowisko cloud / server DEV. Tylko ciągnąć. Przechowuj migracje lokalnie na komputerze, który jest używany do wdrażania kodu i zdalnych migracji bazy danych Prod

Uwagi: 2, 3, 4 - migracje można utrzymywać w repozytoriach, ale powinny obowiązywać ścisłe zasady łączenia pull requestów, dlatego zdecydowaliśmy się znaleźć osobę odpowiedzialną za wdrożenia, czyli jedynego gościa, który ma wszystkie pliki migracyjne - nasze wdrożenie -er. Zachowuje migracje zdalnej bazy danych za każdym razem, gdy mamy jakiekolwiek zmiany w modelach.

Krótka odpowiedź Proponuję wykluczenie migracji w repozytorium. Po scaleniu kodu po prostu uruchom ./manage.py makemigrationsi gotowe.

Długa odpowiedź Myślę, że nie powinieneś umieszczać plików migracji w repozytorium. Zepsuje to stan migracji w środowisku deweloperskim innej osoby oraz w innych środowiskach produkcyjnych i scenicznych. (przykłady można znaleźć w komentarzu Sugar Tang).

Z mojego punktu widzenia celem migracji Django jest znalezienie luk między poprzednimi stanami modelu i nowymi stanami modelu, a następnie serializacja luki. Jeśli twój model zmieni się po scaleniu kodu, możesz w prosty sposób makemigrationsznaleźć lukę. Dlaczego chcesz ręcznie i ostrożnie scalać inne migracje, skoro możesz osiągnąć to samo automatycznie i bez błędów? Dokumentacja Django mówi:

One * (migracje) * są zaprojektowane tak, aby były w większości automatyczne

; proszę, zachowaj to w ten sposób. Aby ręcznie scalić migracje, musisz w pełni zrozumieć, co zmienili inni, i wszelkie zależności tych zmian. To dużo narzutów i podatne na błędy. Więc plik modeli śledzenia jest wystarczający.

To dobry temat na temat przepływu pracy. Jestem otwarty na inne możliwości.