Рабочий процесс для использования Django South с несколькими ветвями кода

Question

Мне интересно, как другие разработчики Django управляют миграцией своих баз данных с помощью South при разработке с несколькими ветвями кода. Позвольте мне привести пример сценария.

Скажем, например, вы начинаете разработку с основной магистрали. Вы создаете ветвь А из ствола. На данный момент последняя версия миграции для app_1 - 0010.

Затем вы создаете миграцию для app_1 в транке, который создает файл миграции 0011_add_name_column. Между тем, в ветви A другой разработчик создает другой файл миграции для того же app_1 в ветви A: 0011_increase_value_column_size.

Ветвь А в конечном итоге сливается обратно в ствол. Когда это произойдет, скажем, последняя версия миграции в app_1 в ветви A - 0020, а в транке последняя версия - 0018, и все они разные миграции. Как видите, состояние файлов миграции испорчено начиная с версии 0011, когда ветвь была разветвлена ​​из ствола ... и все они конфликтуют при слиянии.

Согласно учебнику Юга , единственный способ справиться с этим делом - вручную разрешить все конфликты. Тем не менее, это не совсем желаемое решение, если количество конфликтов является значительным. Как вы обычно справляетесь с этой ситуацией или вообще избегаете ее?

Answer 1

Ну, ответ на этот вопрос не очень прост.

TL; обновление DR : В большинстве случаев, если мы говорим о рабочем процессе магистрали <-> Branch, я бы, вероятно,

1. «Сжатие» новых миграций из ветви A в одну миграцию (или наименьшее возможное)
2. Объединить все изменения / переносы соединительных линий в ветвь А.
3. Переименуйте ветвь А, переходите на 0019 и т. Д.
4. Теперь сливаемся в багажник.

Подробнее

Прежде всего, не имеет значения, если у вас есть несколько миграций с одинаковым префиксом (т. Е. 0011) от объединения разных ветвей, , пока они не изменяют одни и те же модели. Затем вы можете просто запустить миграцию с опцией --merge, чтобы применить неупорядоченные миграции.

Но если у вас есть два разных «пути миграции» из 0011 -> 0018 и 0011 -> 0020 для одного и того же приложения, даже если они не касаются одних и тех же моделей, это не очень красиво. Я думаю, что либо:

1. Эти ветви были разделены в течение очень долгого времени, и в этих двух схемах имеется большое несоответствие. Здесь возможны 2 ситуации:

   • Они не касаются одних и тех же моделей (то есть они не "пересекаются"): вы можете просто применить их не по порядку с помощью --merge, , однако очень вероятно, что затронутые модели должны лучше принадлежать 2 отдельным приложениям.

   • Они делают касаются одних и тех же моделей (что, я полагаю, это, вероятно, ваш случай): я должен согласиться с @chrisdpratt, что лучше всего избегать этой ситуации, координируя / разделяя Работай лучше. Но даже в этом случае, особенно если у вас есть только миграции схемы, и вы не делаете явно конфликтующие миграции схемы в двух ветвях (глупый пример - добавление поля с одинаковым именем к одному и тому же модели в 2 разных миграциях), вполне вероятно, что вы можете просто применить миграции (или, по крайней мере, большинство из них) не по порядку с --merge без проблем. Во многих случаях порядок миграций схемы не имеет значения, даже если они влияют на одну и ту же модель, однако вам необходимо проверить это вручную. А когда возникает проблема, вам просто нужно изменить их нумерацию, автоматического способа ее не существует.

2. Вы генерируете новую миграцию схемы для каждого небольшого изменения схемы: в этом нет ничего плохого во время разработки, но как только функция завершена (готова к объединению), миграции должны быть «сжаты» в одну миграцию (или по крайней мере, меньше миграций, если есть много изменений с некоторой логической группировкой, или если у вас также есть миграции данных). В среде разработчиков, которая уже используется для последней миграции, просто сделать

   • . / Manage.py перенести myapp 0010 - fake
   • удалить миграции 0011-0018
   • . / Manage.py schemamigration myapp schema_changes_for_new_feature_x --auto
   • . / Manage.py migrate myapp 0011 --fake --delete-ghost-migrations

Другое дело, что после слияния двух ветвей с разными миграциями вам часто нужно будет создать методы миграции схемы mergefix (с пустыми вперед / назад), чтобы записать объединенное состояние в «замороженных» моделях. (в противном случае South будет считать, что имеются значительные изменения схемы)

Answer 2

Мой ответ не совершал миграцию, когда это было возможно.Миграции всегда можно восстановить, если они потеряны, поэтому при условии, что никто, кроме меня, не должен запускать мою ветку, просто не фиксируйте свои миграции до самого конца.

Если не считать этого, лучший метод, который я нашел, этопросто относиться к ним как к конфликтам слияния.Когда вы объединяетесь в магистраль, проверьте папку (и) миграции и независимо разрешите каждый конфликт нумерации, переименовав ваши миграции в более высокие номера.

Конечно, ни один из методов не идеален, но вариантов не так многона этом фронте. Собственный совет Юга по этому вопросу - не развиваться в вакууме.Часто объединяйтесь и общайтесь с другими разработчиками, с которыми вы работаете.

Юг не может заменить командную координацию [...] Убедитесь, что ваша команда знает, кто над чем работает, чтобы они не• записывать миграции, которые затрагивают одни и те же части БД в одно и то же время.

Хотя этот совет может показаться разочаровывающим на поверхности, в действительности этот принцип верен.Больше, чем просто миграция, никогда не бывает хорошей идеей, чтобы несколько разработчиков работали над одной и той же частью системы одновременно.Назначьте аналогичные задачи одному и тому же разработчику, который уже работает над этой частью системы, и у вас не возникнет никаких проблем.