Ветвление TFS2010 для частых выпусков и неограниченного обслуживания - PullRequest
Новая
       44

Ветвление TFS2010 для частых выпусков и неограниченного обслуживания

5 голосов
/ 25 февраля 2012

У меня проблемы с поиском хорошей стратегии ветвления, которая позволяет легко объединять и отслеживать наборы изменений в нашей среде.

Краткий обзор управления выпусками выглядит следующим образом:

У нас есть несколько коммерческих продуктов в составе решения.Неизменяемые внешние факторы приводят к необходимости поддерживать несколько версий программного обеспечения в течение неопределенного времени .Релизы являются слишком частыми и обычно в ответ на список улучшений или дефектов и на ОЧЕНЬ агрессивных графиках.Релизы, содержащие только исправления ошибок, обычно представляют собой точечные выпуски, поддерживаемые в родительской ветке выпусков.Релизы с новой функциональностью обычно становятся новой версией / веткой.

Дерево управления исходным кодом выглядит следующим образом: 

- trunk - dev
  - Product ABC
    - ABC 1.0
      -  ABC 1.0.1 (point release same branch)
    - ABC 2.0
  - Product XYZ
    - XYZ 1.0
    - XYZ 2.0

Очевидно, что Dev - это наша ветка разработки, и ожидается, что она не будет стабильной.Изменения Dev, которые проходят экспертную оценку, переносятся в ствол, который мне нравится считать стабильным, но все еще программным кодом.Когда мы добавляем новые функции в ствол (обычно в ответ на проект клиента), мы в конечном итоге приближаемся к выпуску, и я разветвляюсь из ствола в ветку, подобную «Product ABC 2.0» выше.

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

Это просто кажется таким замысловатым планом ветвления, чтоЯ убежден, что это совершенно неправильно или что нет хорошего способа использовать нашу модель и сколько выпусков мы выпускаем и поддерживаем в течение многих лет для разных клиентов.основываться на более простых сценариях выпуска.Есть ли что-то, чего мне здесь не хватает, что могло бы вернуть здравомыслие?

1 Ответ

3 голосов
/ 26 февраля 2012

Увидев много стратегий ветвления, мой первоначальный совет очень прост:

Стремитесь к простейшему плану ветвления, насколько это возможно

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

Очки для рассмотрения:

  • Ветви выпуска становятся доступными только для чтения после выпуска версии (пройдена проверка качества) и был зеленый свет для доставки)
  • Будьте сдержаны при создании нового ветви. Новые ветки должны быть созданы, когда это абсолютно необходимо. Причины могут быть: основная версия, изоляция функции, выпущенный клиент версия, исправление \ исправление изоляции
  • Предпочитайте метки вместо новых веток, когда это возможно. Как только функция будет объединена с основной веткой \ trunk, пометьте ее и запретите дальнейшую регистрацию в ней филиал
  • Как правило, только активно развивающиеся отрасли должен быть онлайн. Избегайте "зомби" веток, удалив ветви, которые были объединены и неактивны
  • Слияние часто
  • Использование CI ночных сборок в качестве первой линии контроля качества

Возможно, ваш сценарий находится где-то посередине между сценариями № 3 (Ветвление и Маркировка) и № 4 (Многофункциональные команды) в Руководство по ветвлению TFS . Тем не менее, сложные планы развития, как правило, разнообразны, так что будьте сами судьей при выборе новой стратегии.

enter image description here

...