Выбор стратегии ветвления и слияния в Team Foundation Server (TFS) - Рекомендации по работе над большим проектом

Written on . Posted in Разработка и тестирование

ОГЛАВЛЕНИЕ

Страница 8 из 8

Рекомендации по работе над большим проектом

Большим группам разработки с длительными циклами разработки присущи следующие черты:

  • Им нужна более сложная структура ветвления и слияния.
  • Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами.
  • Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.

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

Например, при определении схемы слияния (будет ли она выполняться по графику или управляться событиями) необходимо учесть следующее

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

Необходимо найти компромисс между стратегией ветвления/слияния и предполагаемой частотой выполнения сборок. Более глубокая структура ветвления означает большее время интегрирования кода дочерних ветвей в главную ветвь исходного кода. Признаками неверного выбора стратегии ветвления являются:

  • Дефектные сборки, потому что перенос исправлений дефектов в главную ветвь требует слишком много времени.
  • Невыполнение сроков разработки, потому что требуется слишком много времени на распространение внесенных изменений в главную ветвь.
  • На перенос изменений из ветви в ветвь требуется очень много времени.

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

  • My Team Project
    • Development – Контейнер для изолирования активных ветвей разработки
      • Feature A – Изолированная ветвь разработки
        • Source
      • Feature B – Изолированная ветвь разработки
        • Source
    • Main – Главная ветвь интеграции и сборки. Все изменения сводятся воедино здесь.
      • Source
      • Other Asset Folders
    • Releases – Контейнер для ветвей текущей версии и обслуживания
      • Release 2– Активная ветвь обслуживания
        • Source
        • Other Asset Folders
      • Release 3 – Активная ветвь обслуживания
        • Source
        • Other Asset Folders
      • Release 4 – Ветвь, содержащая код, находящийся на этапе подготовки к выпуску, внесение неконтролируемых изменений в который запрещено
        • Source
        • Other Asset Folders
    • Safe Keeping
      • Release 1 – Ветвь архивного хранения старой версии
        • Source
        • Other Asset Folders

Данная структура включает:

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

Заключение

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

При создании ветвей необходимо логически структурировать их таким образом, чтобы затем производить слияние лишь вдоль иерархии (вверх и вниз по ветви), а не поперек иерархии. Слияние поперек иерархии требует достаточно много времени и может приводить к множеству ошибок.

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

форум программирование