Как работать с миграциями Django в команде?

Question

[Александр Дашков]

Работаем в команде над проектом на джанге. Суть проблемы состоит в том, что не совсем понятно как работать с миграциями, каждый работает в своей ветке гита, меняет модели, делает миграции и т.д. При мердже возникают проблемы из-за того, что у каждого свой порядок проведенных миграций. Как надо поступать? Ставить миграции в гитигнор? Тогда какая от них польза, если у каждого своя история миграций?
Всем спасибо.

Comments

[sim3x]

в одной и той же модели?

[Александр Дашков]

sim3x: Чаще всего разные, но чуть вопроса остается
допустим у меня вот такой код
dependencies = [
('patients', '0055_auto_20150512_0957'),
],
а у моего товарища другой номер идет в зависимости и при мердже все сыпится

[sim3x]

Александр Дашков: ('patients', '0055_myawsmmodel__doneby_myawsusername'),

не думаю, что у тебя в команде все имеют одинаковые ники

[sim3x]

Александр Дашков: также как и никто не запрещает ввести в именование номер версии и/или номер спринта, так чтоб сгруппировать миграции по таскам

[Александр Дашков]

sim3x: в принципе от этого ничего не меняется. Автоматическое именование файлов или задавать имена. Т.е. при каждом пуше надо перегенерировать миграции, я правильно понимаю?

[sim3x]

Александр Дашков: нет

разработчики вначале дня говорят друг другу, что они будут менять модель
изначально договариваются, что изменения совершенно не затрагивают друг друга
-- или просто садятся и вместе клепают изменения
Сидор говорит Ануфрию, что его миграция будет иметь имя 0001_666_ххх, Ануфрию нравится другое число 0001_616
В конце рабочего дня Ираклий Сафронович их ТЛ, мерджит их изменения и пушит с изменением версии софта

В итоге на CI-сервере применяется сначала 0001_616_ххх, потом 0001_666_ххх, а потом проганяются все тесты

[sim3x]

Александр Дашков: также можно исключить Ираклия из схемы и сделать правило - кто последний тот и мерджит, с преференцией раздавать тумаки тому кто сделал изменение в коде не предупредив команду

[Александр Дашков]

sim3x: Спасибо, такая схема хорошо подходит.

Answer 1

[sim3x]

Кстати, уже есть топик про ето
https://docs.djangoproject.com/en/1.8/topics/migra...

ну и кастомное имя https://docs.djangoproject.com/en/1.8/ref/django-a...

Comments

[Александр Дашков]

Спасибо, пойду дальше курить документацию

Answer 2

[dovgalmichael]

файлы миграций в игнор у всех,кроме тим-лида группы или какого-то одного человека из команды. а остальные на своем локальном компе будет восстанавливать структуру БД по моделям при работе с со своей локальной веткой.
а суть от них будет при работе с веткой-мастером, в котором будет только код для прода, который собирает тот единственный.
вижу только какой-то такой вариант.
P.S. вопрос актуален, у самого скоро может возникнуть такая проблема на проекте

Comments

[sim3x]

тл может стать узким местом - он ведь человек

[Александр Дашков]

Мы сейчас как раз на примерно такую схему и переходим

[dovgalmichael]

sim3x: ну тут да. однако,если будет вариант лучше, буду только рад! у нас на фирме django - это новинка,выбрали для первого web-проекта вместо чистого PHP,работаем всего две недели и пока только два человека. Но такая же проблема ждет впереди(

[sim3x]

dovgalmichael: в коментах к вопросу расписал две схемы

[dovgalmichael]

sim3x: уже увидел/оценил. спасибо