Чи слід додати файли міграції Django у .gitignoreфайл?
Нещодавно у мене виникало багато проблем із git через міграційні конфлікти і мені було цікаво, чи слід маркувати файли міграції як ігнорування.
Якщо так, то як би я почав додавати всі міграції, які я маю у своїх додатках, і додавати їх у .gitignoreфайл?
Відповіді:
Цитуючи документацію про міграцію Django :
Файли міграції для кожної програми перебувають у каталозі "міграції" всередині цього додатка, і вони розроблені для того, щоб їх було надано та розповсюджено як частина її кодової бази. Ви повинні зробити їх один раз на своїй розробці, а потім виконати однакові міграції на машинах своїх колег, ваших постановочних машинах і, нарешті, ваших виробничих машинах.
Якщо ви дотримуєтеся цього процесу, у вас не повинно виникати конфліктів злиття у файлах міграції.
Під час об'єднання гілок управління версіями ви все ще можете зіткнутися з ситуацією, коли у вас є кілька міграцій на основі однієї батьківської міграції, наприклад, якщо різні розробники ввели міграцію одночасно. Одним із способів вирішення цієї ситуації є запровадження _merge_migration_. Часто це можна зробити автоматично за допомогою команди
./manage.py makemigrations --mergeяка введе нову міграцію, яка залежить від усіх поточних міграцій голови. Звичайно, це працює лише тоді, коли між міграціями голови немає конфлікту, і в цьому випадку проблему доведеться вирішити вручну.
Зважаючи на те, що деякі люди тут пропонували, що ви не повинні здійснювати міграцію для контролю версій, я хотів би розповісти про причини, чому ви насправді повинні це зробити.
По-перше, вам потрібен запис міграцій, застосованих до ваших виробничих систем. Якщо ви розгортаєте зміни у виробництві та хочете перенести базу даних, вам потрібен опис поточного стану. Можна створити окрему резервну копію міграцій, застосованих до кожної виробничої бази даних, але це здається зайвим громіздким.
По-друге, міграції часто містять нестандартний рукописний код. Не завжди можливо автоматично генерувати їх за допомогою ./manage.py makemigrations.
По-третє, міграції повинні бути включені в огляд коду. Вони суттєво змінюються у вашій виробничій системі, і є багато речей, які можуть з ними піти не так.
Отже, коротше, якщо ви дбаєте про свої виробничі дані, будь ласка, перевірте свої міграції до контролю версій.
Ви можете слідувати наведеному нижче процесу.
Можна запустити makemigrationsлокально, і це створить файл міграції. Закладіть цей новий файл міграції в репост.
На мою думку, ти взагалі не повинен працювати makemigrationsу виробництві. Ви можете запустити migrateвиробництво, і ви побачите, що міграції застосовуються з файлу міграції, який ви створили з локальних даних. Таким чином ви зможете уникнути всіх конфліктів.
IN LOCAL ENV , щоб створити файли міграції,
python manage.py makemigrations
python manage.py migrateТепер зробіть ці новостворені файли, щось подібне нижче.
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...У ВИРОБНИЦТВІ ENV виконуйте лише команду нижче.
python manage.py migratemigrateі НІКОЛИ не makemigrationsздійснювати міграції. Ніколи про це не думав.
Цитата з документів 2018 року, Django 2.0. (дві окремі команди = makemigrationsі migrate)
Причина, що є окремі команди для здійснення та застосування міграцій, полягає в тому, що ви будете здійснювати міграції до вашої системи контролю версій та відправляти їх разом із своїм додатком; вони не тільки полегшують вашу розробку, вони також можуть бути використані іншими розробниками та у виробництві.
TL; DR: здійснюйте міграцію, вирішуйте міграційні конфлікти, регулюйте робочий процес git.
Ви відчуваєте, що вам потрібно скорегувати git робочого процесу, а НЕ ігнорування конфліктів.
В ідеалі кожна нова функція розробляється в іншій галузі і об'єднується з запитом на виклик .
PR не може бути об'єднаний, якщо виникає конфлікт, тому тому, хто повинен об'єднати свою функцію, потрібно вирішити конфлікт, включаючи міграцію. Для цього може знадобитися координація між різними командами.
Важливо, хоча ввести файли міграції! Якщо виник конфлікт, Джанго може навіть допомогти вам вирішити ці конфлікти ;)
Я не уявляю, чому б у вас виникли конфлікти, якщо ви якимось чином не редагуєте міграції? Зазвичай це закінчується погано - якщо хтось пропустить деякі проміжні зобов'язання, вони не перейдуть на версію до правильної версії, і їх копія бази даних буде пошкоджена.
Процес, який я дотримуюся, досить простий - щоразу, коли ви змінюєте моделі додатка, ви також здійснюєте міграцію, а потім ця міграція не змінюється - якщо вам потрібно щось інше в моделі, то ви змінюєте модель та здійснюєте нова міграція разом із вашими змінами.
У проектах Greenfield, ви можете часто видаляти міграції і починати з нуля, з міграцією 0001_, коли ви випускаєте, але якщо у вас є виробничий код, ви не можете (хоча ви можете розбити міграцію в одну).
Зазвичай використовується рішення: перед тим, як що-небудь об'єднати в головний, розробник повинен здійснити будь-які віддалені зміни. Якщо в міграційних версіях є конфлікт, він повинен перейменувати свою локальну міграцію (віддалену керовано іншими розробниками, і, можливо, у виробництві), на N + 1.
Під час розробки може бути добре не мігрувати міграції (не додайте ігнору, хоча не робіть addїх). Але після того, як ви розпочали виробництво, вони вам знадобляться для того, щоб схема підтримувала синхронізацію зі змінами моделі.
Потім потрібно відредагувати файл та змінити dependenciesна останню віддалену версію.
Це працює для міграцій Django, а також інших подібних програм (sqlalchemy + alembic, RoR тощо).
Має купу файлів міграції в git безладно. У папці міграції є лише один файл, який ви не повинні ігнорувати. Цей файл є init .py-файлом, якщо його проігнорувати, python більше не буде шукати підмодулі всередині каталогу, тому будь-які спроби імпорту модулів не зможуть. Отже, питання має бути, як ігнорувати всі файли міграції, крім init .py? Рішення полягає в тому, що додайте "0 * .py" до файлів .gitignore, і це виконує роботу ідеально.
Сподіваюся, що це комусь допоможе.
Прогнозуйте міграцію, якщо у вас є окремі БД для середовища розробки, постановки та виробництва. Для дев. Цілі Ви можете використовувати локальний DB sqlite та грати з міграціями локально. Я б рекомендував Вам створити чотири додаткові гілки:
Мастер - Очистіть свіжий код без міграцій. Ніхто не пов'язаний з цією гілкою. Використовується лише для огляду коду
Розвиток - щоденний розвиток. Натиснути / потяг прийнято. Кожен розробник працює над sqlite DB
Cloud_DEV_env - віддалене середовище DEV хмари / сервера. Тільки тягніть. Зберігайте міграції локально на машині, яка використовується для розгортання коду та віддалених міграцій бази даних Dev
Cloud_STAG_env - віддалене середовище STAG хмари / сервера. Тільки тягніть. Зберігайте міграції локально на машині, яка використовується для розгортання коду та віддалених міграцій бази даних Stag
Cloud_PROD_env - віддалене середовище DEV хмари / сервера. Тільки тягніть. Зберігайте міграції локально на машині, яка використовується для розгортання коду та віддалених міграцій бази даних Prod
Примітки: 2, 3, 4 - міграції можна зберігати в репост, але повинні бути чіткі правила об'єднання запитів на виклики, тому ми вирішили знайти людину, відповідальну за розгортання, тому єдиний хлопець, який має всі файли міграції - наш розгортання -er. Він зберігає віддалені міграції БД щоразу, коли ми змінюємо Моделі.
Коротка відповідь
пропоную виключити міграцію в РЕПО. Після злиття коду просто запустіть ./manage.py makemigrationsі все налаштовано.
Довга відповідь Я не думаю, що ви повинні розміщувати файли міграції в репо. Це зіпсує міграційні стани в середовищі розробників інших людей та інших умовах середовища та програми. (для прикладів зверніться до коментаря Sugar Tang).
На мій погляд, метою міграції Джанго є пошук розривів між попередніми модельними станами та новими модельними станами, а потім серіалізація розриву. Якщо ваша модель зміниться після злиття коду, ви можете просто зробити, makemigrationsщоб виявити прогалину. Чому ви хочете вручну та обережно об’єднати інші міграції, коли ви можете досягти того ж автоматично та без помилок? Документація Джанго говорить:
Вони * (міграції) * розроблені таким чином, щоб бути в основному автоматичними
; будь ласка, зберігайте так. Щоб об'єднати міграції вручну, ви повинні повністю зрозуміти, що змінили інші та будь-яку залежність змін. Це багато накладних витрат та помилок. Тож файлу моделей відстеження достатньо.
Це хороша тема робочого процесу. Я відкритий для інших варіантів.
manage.py makemigrations --mergeдля мене працює повністю автоматично.
makemigrations some_app, це стосуватиметься не тільки моделей, які перебувають під його контролем, але й інших пов'язаних моделей. Тобто файли міграції (00 * _ *) в інших додатках будуть змінені. А це спричиняє багато конфліктних проблем під час натискання на GitHub або його витягування. Оскільки наразі наша система не готова до виробництва, ми просто.gitignoreфайл міграції. Ми досі не знаємо, як це вирішити, коли система прийде у виробництво. У когось є якісь рішення?