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

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

ОГЛАВЛЕНИЕ

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

Типовые сценарии на практике

Рассмотрим типовые сценарии ветвления:

  • Сценарий 1 – Нет ветвления. Группа работает только с основным деревом исходного кода. В данном случае ветви не создаются, и в изоляции нет необходимости. Такой сценарий обычно подходит для небольших или средних групп, где не требуется изоляция по группам или по функциональным возможностям и не нужно изолировать версии, готовые к выпуску.
  • Сценарий 2 – Ветвление для выпуска версии. Группа создает ветви для поддержки выпускаемой версии. Это второй наиболее распространенный случай, когда ветвление используется для стабилизации выпускаемой версии. В данном случае группа создает ветвь перед выпуском версии, чтобы стабилизировать ее, и затем, после выпуска версии ПО, вносит изменения из ветви выпущенной версии в основную ветвь исходного кода.
  • Сценарий 3 – Ветвление для обслуживания. Группа создает ветвь для сохранения старой сборки. В данном случае ветвь создается с целью обслуживания, чтобы не дестабилизировать сборки, находящиеся в производственной эксплуатации в настоящее время. Изменения этой ветви могут, как переноситься, так и не переноситься в основное дерево. Например, для некоторой группы пользователей может создаваться решение для быстрого исправления дефекта, которое не требуется включать в основную сборку.
  • Сценарий 4 – Ветвление для разработки функциональной возможности. Группа создает ветви на основании имеющихся функциональных возможностей. В данном случае создается ветвь разработки, все работы ведутся в ней и затем все выполненные изменения переносятся в основную ветвь исходного кода. Создание отдельных ветвей для функциональных возможностей позволяет работать над ними параллельно.
  • Сценарий 5 – Ветвление для изоляции группы. Ветви создаются с целью изоляции подгрупп, чтобы обеспечить им возможность работы без конфликтов, порождаемых несовместимыми между собой изменениями в исходном коде, или чтобы они могли работать параллельно и выполнять синхронизацию по завершении собственных этапов, характерных для этой группы.

В своей работе разработчик может столкнуться с одним и более сценариев. Их следует использовать как эталон для определения возможности применения той или иной рекомендации в конкретном случае.

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