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

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

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

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

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

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

Ответы

Ответ 1

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

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

  • "Сжать" новые миграции из ветки А в единую миграцию (или наименее возможно)
  • Объединить все изменения/перемещения внешних линий в Branch A.
  • Переименовать ветвь А миграции до 0019 и т.д.
  • Теперь объединитесь с багажником.

Подробнее

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

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

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

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

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

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

    • ./manage.py migrate 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 будет думать, что есть замечательные изменения схемы)

Ответ 2

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

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

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

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

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