Заметки консультанта

Шамрай Александр Владимирович

TFS Branching Guidance – Main 2.0

<<Назад

Оригинал – TFS Branching Guide — Main 2.0

TFS Branching Guidance Release 2.0, 12/19/2008

Main article

VSTS Rangers

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

TFS Branching Guidance – 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 упрощен к простому нажатию правой кнопкой мыши и выбору команды 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. Любые исправления, поставленные от ветви релиза, будут включать все предыдущие исправления этой ветви.

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

  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. Нет потребности в слиянии без базовой версии.

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

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

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

  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 для следующих главных релизов.

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

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

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

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

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

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

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

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

  • Главная ветвь должно собираться ежедневно, чтобы задавать команде разработки ежедневный ритм к работе.
  • У каждого потока должен быть путь нормального слияния (обратная интеграция) назад к главному потоку (т.е. никакого слияния без базовой версии).
  • Ошибки и сбои в главной ветви должны немедленно устраняться.
  • Никакого прямого внесения изменений в главную ветвь не должно быть; только настройка сборок и сборочных тестов.
  • Успешная сборка главной ветви говорит о том, что дочерние потоки разработки должны выполнить прямую интеграцию от главного.
  • Команды 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). Почти у всех сервисных проектов для программных продуктов есть потребность в таких классах релиза, поэтому их поддержку в план ветвления релиза мы установили с самого начала. Заметьте, что все 3-и ветви созданы в одно время, чтобы гарантировать правильную взаимосвязь родитель/дочерняя ветвь.

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

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

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

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

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

Интеграция

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

<<Назад

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: