Microsoft Visual Studio Team Foundation Server Branching Guidance 2010 Main

<<Назад

Оригинал – TFS Branching Guide – Main 2010 v.1

VS 2010 TFS Branching Guidance Release 2010, 12/14/2009

Main article

VSTS Rangers

Перевод Шамрай А.В.

Microsoft Visual Studio Team Foundation Server Branching Guidance 2010 Main

Bijan Javidi, James Pickell, Tina Erwee, Willy-Peter Schaub

Microsoft Corporation

Оглавление

Введение

Словарь

План Ветвления – быстрое начало

Основной план ветвления

Стандартный план ветвления

Расширенный план ветвления

Развитый план ветвления

Главная ветвь

О версионировании …

Все, что мне нужно, это MAIN …

Ветви разработки

Множественные ветви разработки

Ветви релиза

Интеграция

Качество сборки

Заключение

Введение

Добро пожаловать в руководство по ветвлению Team Foundation Server! C первого выпуска этого руководства в 2007 мы получили много положительных ответов, подтверждающих полезность этого руководства для планирования, реализации и поддержки ветвления. Используя отзывы от пользователей, мы, команда Microsoft VSTS Most Valuable Professionals (MVPs) и консультантов Microsoft Services, обновили руководство, представленное в этом документе, разработанного как часть проекта VSTS Ranger. Некоторые части настоящего документы были сохранены и в руководство введены 3 новые темы.

Это руководство предназначено для групп уровня 200-300 пользователей Microsoft TFS. Целевая группа рассматривается как промежуточное звено перед опытными пользователями TFS, которая имеет глубокое понимание использования продукта в реальной среде. Некоторые части этого руководства могут быть полезными для новичков и экспертов TFS, но пользователи этих уровней квалификации не рассматриваются как основные для этого руководства.

Перед реализацией Вашего плана ветвления, обратите внимание на следующее предостережение – каждая ветвь имеет свои затраты, поэтому удостоверьтесь, что Вы получите некую выгоду от ветвления. Механизм создания ветви в TFS упрощен к простому нажатию правой кнопкой мыши и выбору команды Branching and Merging | Branch. Однако общие издержки ветвления определяются уменьшением скорости передачи кода в главный поток, а решение конфликтов слияния и дополнительное тестирование могут быть дорогими. Перед созданием ветви пользователь должен быть уверен, что ветвь действительно необходима, и необходимо всегда задавать себе вопрос «как этот поток будет поддерживаться в моем проекте разработки?» Читатели могут думать об этом как о ROI ветвления. Но это не метрика, которую мы можем собрать; скорее это общий вопрос, который нужно задать перед созданием ветки. Выполняя поддержку ветвления с точки зрения необходимого уровня изоляции для разработки или формирования релизов, мы надеемся избежать ситуаций, что это руководство будет принято как готовое решение, и может быть создан излишне сложный план ветвления.

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

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

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

Словарь

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

Ветви разработки (DEVELOPMENT) – изменения для следующей версии.

Главный (MAIN) поток – этот соединяющая ветвь между ветками разработки и релиза. Эта ветвь должна представлять устойчивую версию продукта, которую можно предоставлять QA или внешним командам.

Пакет обновлений (SERVICE PACK (SP)) – набор исправлений и функциональных возможностей, предназначенных для предыдущей версии продукта.

Исправление (HOTFIX) – изменения, которые направлены на исправление ошибки или сбоя сервиса.

Ветвь релиза (RELEASE) – ветвь, где установлены основные исправления перед выпуском главного релиза продукта. После выпуска продукта этот поток обычно становится только для чтения.

Прямая интеграция (FORWARD INTEGRATE (FI)) – Слияние от родительской к дочерней ветви.

Обратная интеграция (REVERSE INTEGRATE) – Слияние от дочерней к родительской ветви.

Поставка релиза (RELEASE VEHICLE) – Как Ваш продукт попадает к Вашему клиенту (например, основной релиз, исправления и/или пакеты обновлений).

План Ветвления – быстрое начало

«Сохраняйте креативность для Вашего продукта … не план ветвления.» – аноним

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

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

Цель основного, стандартного и расширенного планов ветвления, состоит в том, чтобы покрыть большинство сценариев ветвления. Присылайте, пожалуйста, свои сценарии, которые не попадают под данное руководство, в раздел сообщества http://codeplex.com/TFSBranchingGuideII. Мы надеемся увеличить сообщество Codeplex, чтобы покрыть альтернативные (но все еще использующиеся) варианты ветвления.

Основной план ветвления

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

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

Дополнительные релизы поддерживаются созданием дополнительных ветвлений для каждого релиза продукта. Каждый поток релиза является дочерним для главного потока, и равноправен к другим потокам релиза (например, release2.0 равноправен к release3.0 и оба дочерние к главной ветви).

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

Рисунок 1. Основной план ветвления

Рисунок 2. Основной план ветвления — визуализация иерархии

Рисунок 3. Основной план ветвления – файловая структура

Рисунок 4. Основной план ветвления – связь между ветвями

Рисунок 5. Основной план ветвления – визуализация изменений – иерархия

Рисунок 6. Основной план ветвления – визуализация изменений – временная шкала

Основной план ветвления будет приемлем для Вашей организации, если у Вас выполняются некоторые из следующих критериев:

1. У Вас есть единственный главный релиз, который поставляется (т.е. единственная поставка релиза) клиентам.
2. Ваша модель обслуживания основана на обновлении клиентов к следующему главному релизу.
3. Любые исправления, поставленные от ветви релиза, будут включать все предыдущие исправления этой ветви.

Основные элементы этого плана включают

1. Ветви разработки DEVELOPMENT для следующей версии.
   1. Сосредоточенны на широких, плоских ветвях, чтобы обеспечить устойчивость потока кода к главной MAIN ветви и затем назад к соответствующему потоку разработки DEVELOPMENT
   2. Работа в ветвях разработки DEVELOPMENT может быть разделена по функциональным возможностям, организации или временным сотрудничеством.
   3. Каждый поток разработки DEVELOPMENT должен быть полным ответвлением от главной ветви MAIN.
   4. Ветви разработки DEVELOPMENT должны собираться и проходить сборочное тестирование, как и в главной ветви MAIN.
   5. Используйте прямую интеграцию с каждой удачной сборкой главной ветви MAIN.
   6. Обратная интеграция основывается на некоторых объективных критериях команды разработки (например, внутренние ворота качества (quality gates), конец спринта и т.д.).
2. Ветвь релиза, где выполняется поставка главного релиза.
   1. Ветвь релиза RELEASE дочерняя к главной ветви MAIN.
   2. После того как Ваш продукт выпускается из ветви релиза RELEASE, ветвь релиза RELEASE устанавливается в режим только для чтения.
   3. Изменения от ветви релиза RELEASE в главной поток MAIN переходят с помощью обратной интеграции. Это одностороннее слияние. Как только ветвь релиза создана, главный поток MAIN может принимать изменения для следующей версии, не утвержденных для ветви релиза.
   4. Дублируйте план ветви релиза RELEASE для следующих главных выпусков.
3. Изменения должны вноситься только в один поток
   1. У всех ветвей есть путь слияния обратно к главной ветви MAIN.
   2. Нет потребности в слиянии без базовой версии.

Стандартный план ветвления

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

Рисунок 7. Стандартный план ветвления

Рисунок 8. Стандартный план ветвления — визуализация иерархии

Рисунок 9. Стандартный план ветвления – файловая структура

Рисунок 10. Стандартный план ветвления – визуализация изменений – иерархия

Рисунок 11. Стандартный план ветвления – визуализация изменений – временная шкала

Этот план будет приемлем для Вашей организации, если у Вас выполняются некоторые из следующих критериев:

1. У Вас есть множественные поставки (например, главный релиз и дополнительные пакеты обновления для этого релиза).
2. Вы хотите обеспечить параллельную разработку пакета обновлений и следующей версии продукта.
3. У Вас есть согласованные требования к тому, чтоб у Вас была точная копия исходных кодов для релиза.

Все ключевые пункты руководства от основного плана применимы к стандартному плану. У стандартного плана есть эти дополнительные элементы:

1. Ветви релизов RELEASE для хранения релизов и создания пакета обновления
   1. Дерево релиза RELEASE (т.е. ветви SP и RELEASE) ответвлены от главного потока MAIN в одно время в виде следующих связей родитель/дочерняя ветвь: MAIN->SP->RELEASE.
   2. Продукт выпускается из ветви релиза RELEASE, затем эта ветвь устанавливается в режим только для чтения.
   3. Сервисные изменения вносятся в ветвь пакета обновления (SP).
   4. Изменения сервисной ветви SP объединяются только в одну сторону с главным потоком MAIN (SP->MAIN).
   5. Исправления ошибок, которые реализовывались в ветви релиза перед выпуском продукта, должны быть объедены назад с главной ветвью MAIN через сервисный поток SP (RELEASE->SP->MAIN).
   6. Дублируйте план дерева релиза RELEASE для следующих главных релизов.

Расширенный план ветвления

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

Рисунок 12. Расширенный план ветвления

Рисунок 13. Расширенный план ветвления — визуализация иерархии

Рисунок 14. Расширенный план ветвления – файловая структура

Рисунок 15. Расширенный план ветвления – визуализация изменений – иерархия

Рисунок 16. Расширенный план ветвления – визуализация изменений – временная шкала

Все ключевые пункты руководства основного и стандартного планов включаются в расширенный план. У расширенного плана есть эти дополнительные элементы.

1. Ветви релиза RELEASE используются для хранения релизов, исправлений и разработки пакетов обновлений
   1. Дерево релизов RELEASE (т.е. SP, HOTFIX и RELEASE) формируются от главной ветви MAIN в одно время, в следующей иерархии: MAIN->SP->HOTFIX->RELEASE.
   2. После создания дерева RELEASE любые заключительные исправления, влияющие на выпуск, выполняются в ветви RELEASE. Сборка для релиза формируется в ветви RELEASE. После выпуска продукта ветвь RELEASE устанавливается в режим только для чтения. Это гарантирует, что у Вас будет точный набор исходных кодов, которые использовались для выпускаемой версии продукта.
   3. Внесение изменений выполняется в соответствующем потоке релиза, к которому они относятся (например, исправления регистрируются в ветви исправлений HOTFIX). Поддержка — это затраты, поэтому попытайтесь объединить все исправления, связанные со специфическим релизом, в соответствующей ветви HOTFIX. Если необходимы определенные исправления для заказчика, то тогда формируется отдельная ветвь HOTFIX именно для этого заказчика. Отдельные ветви исправлений HOTFIX под заказчика должны использоваться редко.
   4. Изменения ветвей исправлений HOTFIX и пакетов обновлений SP переходят в главную ветвь MAIN односторонним слиянием (HOTFIX->SP->MAIN).
   5. Как только исправления были объединены из ветви HOTFIX в ветвь SP, любой релиз из SP будет включать все исправления релиза + любые изменения, выполненные непосредственно в ветви SP. Примечание: если Ваш план релизов включает один или более пакетов обновления, Вы можете рассмотреть развитый план ветвления, представленный в следующем разделе.
   6. Дублируйте план ветвления релиза RELEASE для следующих главных выпусков.

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

Развитый план ветвения

Рисунок 17. Развитый план ветвления

Рисунок 18. Развитый план ветвления — визуализация иерархии

Рисунок 19. Развитый план ветвления – файловая структура

Рисунок 20. Развитый план ветвления – визуализация изменений – иерархия

Рисунок 21. Развитый план ветвления – визуализация изменений – временная шкала

Главная ветвь

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

Атрибуты главной ветви

• Главная ветвь должно собираться ежедневно, чтобы задавать команде разработки ежедневный ритм к работе.
• У каждого потока должен быть путь нормального слияния (обратная интеграция) назад к главному потоку (т.е. никакого слияния без базовой версии).
• Ошибки и сбои в главной ветви должны немедленно устраняться.
• Никакого прямого внесения изменений в главную ветвь не должно быть; только настройка сборок и сборочных тестов.
• Успешная сборка главной ветви говорит о том, что дочерние потоки разработки должны выполнить прямую интеграцию от главного.
• Команды QA должны иметь возможность получить для проверки любую сборку из главной ветви.

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

О версионировании …

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

Пример:

MAIN сборка 1.0.27.0

Dev_team1 сборка 1.0.25.0

Для ветви Dev_team1 2 дня не проводилась прямая интеграция с MAIN, если для MAIN сборка проводится ежедневно.

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

Все, что мне нужно, это MAIN …

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

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

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

Если Вам необходим совет относительно ветвления, подумайте об этом:

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

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

Ветви разработки

«Давность синхронизации Вашей ветви с главной ветвью соответствует Вашему уровню безумия» – аноним

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

Прежде, чем создать ветвь разработки, удостоверьтесь, что Вы можете сделать следующее:

• Выбор родительской ветви – если Ваши изменения сосредоточены над разработкой следующего релиза продукта, то родительской ветвью должен быть главный поток MAIN.
• Ветвь от последнего работающего состояния родителя – формируйте ветвь от последней успешной сборки родительской ветви. Должна быть метка, ассоциированная с родительской сборкой, эту метку можно использовать как начальную точку для дочерней ветви. При создании ветви разработки, ее состояние должно быть такое, как и у родителя (т.е. удачная сборка и прохождение сборочных тестов).
• Частая прямая интеграция – цель заключается в том, чтоб проводить синхронизацию с главным потоком не реже чем в 1-2 дня. В идеале прямая интеграция должна проводиться после каждой удачной сборки и прохождения сборочных тестов в родительской ветви.
• Обратная интеграция от дочерней ветви к родительской основана на качестве. Минимальные требования к обратной интеграции:
  • Быть в синхронизации с родительской ветвью
  • Удачная сборка
  • Выполнение сборочных тестов

Множественные ветви разработки

Ранее в этом документе мы описали возрастающую расходы на каждую ветви. Однако, есть несколько сценариев, когда необходимо применять множественные ветви разработки. Самые общие сценарии ниже:

Ломающие изменения

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

• Ветвь должна быть от родителя с последними изменениями (обычно MAIN или другая ветвь DEV).
• Частая прямая интеграция, по крайней мере каждый день.
• Собирайте и выполняйте сборочные тесты, по крайней мере  для ветви ломающих изменений.
• Вносите Ваши изменения, соберите и выполните все сборочные тесты прежде, чем выполнить обратную интеграцию для ломающих изменений и корректных изменений родителю.
• Просмотрите изменения в родительском потоке, которые были сделаны между последней прямой интеграцией к Вашей ветви ломающих изменений и обратной интеграцией (это должн быть небольшой промежуток, меньше чем нескольких часов), чтобы определить должны ли эти изменения быть обновлены.
  • Например, может быть новый компонент, который был зарегистрирован в родителе и не включен в Ваше последнее слияние к ветви ломающих изменений. Эта подпрограмма могла быть не обновлена и может сломать сборку или сборочные тесты.
• После того, как ломающее изменение было объединено обратной интеграцией, ветвь может быть заморожена (то есть никаких объединений или внесения изменений) пока не будет необходимости для следующего ломающего изменения. Следующая прямая интеграция от родителя сделает эту ветвь актуальной снова.

Разделение работы по возможностям системы

В идеале команда может продуктивно работать в одной ветви. Обнаружение дефектов как можно раньше является правилом многих методологий разработки. Однако, некоторые команды или из-за их рабочего стиля, или по технической причине могут просто «задушить», когда другие имеют доступ к их отдельной возможности системы.
Например, одна группа, хочет обеспечить итеративность и тестирование их возможности, но хочет передавать функциональность другим группам по некоторым управляемым методам. Один из методов контролируемой передачи разрабатываемых возможностей — это использование ветвей для возможности системы.
Ветви по возможностям могут быть добавлены в любое время, если у Вас есть по крайней мере основной план перехода (т.е. DEV, MAIN и RELEASE). Обычно проект начинают с одной ветвью разработки. Если одна команда хочет управлять, когда другие используют их часть, то создается вторая ветвь разработки (т. е. дочерняя от MAIN и равноправная ветви разработки).
Перед созданием ветви рассмотрите следующее:

• Выполняется полное ветвление радительского потока (обычно Main), чтоб изолированная часть системы могла быть собрана вместе с другими компонентами.
• Частая прямая интеграция (идеально один раз в день или после каждой успешной сборки в родительской ветви), чтобы удостовериться, что изолированный функционал остается совместимым с последними изменениями от другой команды разработки.
• Удостоверьтесь, что сборочнные тесты для других компонентов выполняются в ветви изолированной возможности системы. В идеале, если изменения для возможности системы в этой ветви нарушат работу другой возможности, то это будет определено и исправлено в этой ветви перед обратной интеграцией к MAIN.
• Обратная интеграция к MAIN рассматривается как “релиз возможности” для других команд разработки. Как только будет выполнена обратная интеграция другие команды будут использовать эту версию функционала до следующей обратной интеграции.
• Когда для MAIN выполняется ветвление для релиза (текущей версии), финальные исправления ошибок влияющих на поставку должны вноситься в ветви RELEASE . Ветвь возможности только для разработки следующей версии. В этом примере, когда для MAIN выполняется ветвление для релиза, все ветви DEV могут начать разрабатывать следующую версию (vNext).

Разработка следующей версии

Когда команды начинают реализовывать свои текущие рабочие элементы, они будут начинать  формировать следующую версию. Пока ветвь RELEASE не создана от MAIN нет никакого соответствующего места, чтобы регистрировать изменения для следующей версии. Без руководства некоторые индивидумы (конечно в хорошем смысле) выполнят много неестественных действий для регистрации изменений следующей версии и исключения их из сборки. Это кажется безвредным, но в конечном счете вызовет проблемы в промежутке от несобравшихся сборок к поставке кода следующей версии в Вашем текущем релизе (имеющего потенциальные интелектуальную собственность и юридические последствия в зависимости от коммерческого значения Ваших изменений для следующей версии).
Рекомендуемое решение состоит в том, чтобы создать ветвь разработки от MAIN для работы над следующей версией. Вы должны создавать эту веть только в случае необходимости, так как присутствие ветви “следующей версии” будет постепенно отвлекать группу от поставки текущей версии продукта.
Условия для этой ветви:

• Полное ветвление от родительского потока (обычно от MAIN) так код для следующей версии собирается наряду с неизменившимся кодом.
• Частая обратная интеграция (идеально один раз в день или когда прошла успешно сборка в родительского потоке), чтобы быть уверенным,  что изменения для следующей версии остаются совместимыми с последними изменениями от других команд разработки.
• Увеличение номера сборки (в идеале major или minor), чтобы идентифицировать какие сборки из этой ветки для следующей версии (vNext).
• Удостоверьтесь, что все инструменты и тестовый код для “следующей версии” находятся в этой же ветви.
• НЕ применяйте прямую интеграцию этой ветви с MAIN, пока для MAIN не было сделано соответвующей ветви релиза. Обратная интеграция от ветви “следующей версии” к MAIN указывает, что все команды начинают работу над следующей версией и любые исправления для поставки продукта текущей версии будут сделаны в соответствующей ветви релиза.

«Рабочие» или временные ветви

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

1. Возможно ли использовать отложенные изменения? Часто разработчики хотят иметь возможность хранить или предоставлять общий доступ к изменениям. Отложенные изменения обеспечат выполнение обеих этих задач, сохраняя изменения в базе данных TFS, но не передавая их в ветвь.
2. Есть ли другой рабочий элемент, над которым Вы должны работать? Иногда некоторые работы не видны отдельным участникам.
3. Работа в ветви “следующей версии”, упомянающейся выше, если изменение одобрено для релиза следующей версии.
4. Если работа действительно не связана с проектом и для обучения разработчика используется TFS 2010 “basic edition”, то создается отдельный экземпляр TFS на рабочем месте разработчика. Это позволяет полностью отделиться от промышленного TFS, который использует команда разработки. Это можно использовать для проектов обучения, которые не будут использоваться в дальнейшем.

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

Ветви релиза

«Быть там исправлениям!» – аноним

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

Расширенный план ветвления предполагает, что Вашему продукту необходима параллельная разработка над исправлениями, пакетами обновлений и над следующей версией (MAIN). Почти у всех сервисных проектов для программных продуктов есть потребность в таких классах релиза, поэтому их поддержку в план ветвления релиза мы установили с самого начала. Заметьте, что все 3-и ветви созданы в одно время, чтобы гарантировать правильную взаимосвязь родитель/дочерняя ветвь.

Успешная стратегия ветвления релиза обеспечивается следующими 3-мя сценариями.

1. Разработчики должны только один раз регистрировать изменения в ветви соответствующей поставке релиза, для которой эти изменения предназначены (т.е. исправления вносятся в ветвь исправлений продукта).
2. Нет необходимости в слиянии без базовой версии. Создайте нормальный путь слияния обратно к главной ветви, используя иерархическую структуру ветвления, основанную на поставках релиза.
3. Уменьшение риска регрессии. При создании связей родительская/дочерняя ветвь между главной ветвью, ветвью пакета обновлений и ветви исправлений, изменения нормально будут объединяться в следующий релиз (т.е. исправления объединяются в ветвь пакета обновлений по их пути к главному потоку), что уменьшает риск регрессии ошибки в будущих релизах.

После того, как ветки релизов созданы, изменения от главного потока не должны использовать прямую интеграцию в ветви релиза. Изменения должны объединяться по одному пути от релиза к главной ветке. Кроме того, изменения должны всегда объединяться через промежуточные ветви (т.е. RELEASE-> HF-> Service pack-> MAIN), чтобы гарантировать, что исправления ошибок останутся актуальными для последующих релизов.

Необходимо отметить что, как только Вы выполните последнее изменение в главном релизе (т.е. ветвь релиза RELEASE на рисунке выше), эта ветвь должна быть установлена в режим только для чтения. Эта ветвь сохраняется только в целях согласования. Единственный верный способ определить состояние вашего исходного кода для ветвления и поставки продукта из этой ветви, это время истории изменений в TFS для меток.

Интеграция

«…, когда желания совпадают с возможностями». – аноним

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

• Сводите ветвление к минимуму.
• Частота прямой интеграции с главной ветвью в идеале должна быть не реже, чем в 1-2 дня.
• Частота обратной интеграции определяется результатами сборки и автоматизированных тестов.

Качество сборки

«Это работает у меня.» – аноним

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

Сборочные тесты должны отвечать следующим 3 требованиям.

1. Полностью автоматизированы
2. Воспроизводимы на 100 %
3. Сборочные тесты считаются проваленными, если более 30 % тестов не выполнилось.

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

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

TFS 2010 Разрешения для ветвей и слияния

TFS 2010 вводит два новых вида разрешений для ветвления и слияния:

• Управление ветвью
• Слияние

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

Управление разрешениями ветви

Пользователю необходимо разрешение Управления ветвью по указанному пути для:

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

Разрешение Управление ветвью относится только к ветвям (или папкам, которые были преобразованы в ветви). Пользователь не ограничен от ветвления обычных папок, для которых это разрешение было запрещено.

Разрешение Управление ветвью ограничено по определенному пути. Ветви могут еще быть организованы в папки. Таким образом, разрешение Управление ветвью позволяет команде организовать их ветви так, что некоторые ветви могут быть дальше разветвленными пользователями, а другие нет.

Например, команда может запретить Участникам разрешение Управление ветвью для всех ветвей, находящихся по путям: $/<TeamProject>/Main и $/<TeamProject>/Releases, но позволить Участникам разрешение Управления ветвью для ветви фукционала, находящейся в $/<TeamProject>/Development. С этими разрешениями члены группы TFS Участники могут создавать дочерние ветви для разработки (из существующей ветви возможности), но не может создавать новые ответвления от ветки релиза или от главного потока.

Разрешение Слияние

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

История изменений и визуализация изменений

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

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

Изменение родителя для ветви

TFS 2010 предоставляет возможность изменить отношения родитель-дочерняя между ветвями.

Заключение

«Нет иной судьбы, кроме той, что мы делаем сами.» – аноним

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

<<Назад