Поддержание южных миграций на вилках Django

Я работаю над довольно сложным проектом Django (более 50 моделей) с некоторой сложной логикой (множество различных рабочих процессов, представлений, сигналов, API-интерфейсов, фоновых задач и т.д.). Позвольте называть это project-base. В настоящее время используется миграция Django 1.6 + South и немало других сторонних приложений.

Теперь одно из требований - создать вилку этого проекта, которая добавит некоторые поля/модели здесь и там, а также дополнительную дополнительную логику. Позвольте называть это project-fork. Большая часть дополнительной работы будет поверх существующих моделей, но также будет несколько новых.

По мере того, как project-base продолжает развиваться, мы хотим, чтобы эти функции также попадали в project-fork (так же, как rebase/merge в git -land). Дополнительные изменения в project-fork не будут объединены обратно в project-base.

Что может быть наилучшим возможным способом для этого? Вот некоторые из моих идей:

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

  • Не изменяйте ANY из исходных моделей project-base и вместо этого создавайте новые модели в разных приложениях, которые ссылаются на старые модели (т.е. с помощью OneToOneField). Дополнительная логика может оказаться в старых и/или новых приложениях.

  • Ваша идея здесь, пожалуйста:)

Я бы пошел с вариантом 1, поскольку он кажется менее сложным в целом, но может подвергнуть больший риск. Вот как я это вижу:

Миграции на project-base:

  • 0001_project_base_one
  • 0002_project_base_two
  • 0003_project_base_three

Миграции на project-fork:

  • 0001_project_base_one
  • 0002_project_fork_one

После слияния миграции будут выглядеть следующим образом:

  • 0001_project_base_one
  • 0002_project_base_two
  • 0002_project_fork_one
  • 0003_project_base_three
  • 0004_project_fork_merge_noop (добавляется для слияния изменений в обоих проектах)

Есть ли подводные камни, использующие этот подход? Есть ли лучший способ?

Спасибо за ваше время.

ОТВЕТЫ

Ответ 1

Официальный южный рабочий процесс:

Официальная рекомендация Юга - попробовать флаг --merge: http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow

Это, очевидно, не будет работать во всех случаях, по моему опыту он работает в большинстве случаев.

Ловушки:

  • Несколько изменений в одной и той же модели могут по-прежнему прерываться
  • Повторяющиеся изменения могут сломать вещи.

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

Мои личные рабочие процессы в этих случаях:

С маленькими вилками, где изменения модели очевидны с самого начала:

  • Discus, какие изменения модели необходимо будет сделать для fork
  • Примените эти изменения к обоим/всем ветвям как можно быстрее, чтобы избежать конфликтов.
  • Работа над вилкой....
  • Объединить вилку, которая не дает никаких новых перемещений.

С большими вилками, где изменения не всегда очевидны и/или будут меняться снова:

  • Сделайте обычную вилку и материал для разработки, пытаясь максимально обновиться с последней ветвью мастера/разработки
  • Перед слиянием обратно отбросьте все схемы миграции в fork
  • Слить все изменения с мастера/разработки
  • Восстановить все необходимые изменения схемы.
  • Объединить для разработки/мастеров