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

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

TFS Branching Guidance – Scenarios 2.0

<<Назад

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

TFS Branching Guidance Release 2.0, 12/19/2008

Scenarios

VSTS Rangers

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

TFS Branching Guidance – Scenarios

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

Microsoft Corporation

Оглавление

Описание сценариев

Сценарий #1: Модель ветвления для одной команды

Описание сценария: Модель ветвления для одной команды

Определение ветвей для этого сценария

Шаги сценария

Структура на Team Foundation Server

Артефакты системы версионного контроля для сценария

Сценарий #2: Параллельная разработка исправлений, пакета обновлений и следующей версии

Описание сценария: Параллельная разработка исправлений, пакета обновлений и следующей версии

Определения ветвей для этого сценария

Шаги сценария

Структура на Team Foundation Server

Артефакты системы версионного контроля для сценария

Важные моменты сценария

Сценарий #3: Сценарий использования ветвлений и меток

Описание сценария: Ветвление от меток

Определения ветвей для этого сценария

Шаги сценария

Структура на Team Foundation Server

Артефакты системы версионного контроля для сценария

Важные моменты сценария

Соглашения по среде и расположению сборки для сценариев

Соответствие структуры ветвей и среды

Описание сценариев:

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

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

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

В каждом сценарии представлены ситуации, которые встречались в команде разработки Wood Grove Banking. Результирующие структуры потоков разработки и операций объединения представлены и подробно описаны в этом документе.

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

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

Сценарий #1: Модель ветвления для одной команды

Рисунок 1. Модель ветвления для одной команды

Описание сценария: Модель ветвления для одной команды

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

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

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

Код помечен в MAIN фактическим номером версии и ветвь DEV помечена в начале разработки как следующая версия, в этом сценарии это происходит при создании версии 1.1. Поскольку разработка начинает реализовываться, версия кода в MAIN остается стабильно в V1.0, в то время как разработка продвигается. В определенные моменты времени выполняется прямая интеграция от ветви MAIN к ветви разработки, чтобы гарантировать, что команда разработки понимает значение изменений, которые они выполняют для V1.1.

В некоторый момент времени ветвь разработки стала отвечать поставленным стандартам качества и готова для выпуска. Теперь выполняется обратная интеграция ветви DEV к MAIN.

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

Определение ветвей для этого сценария

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

Шаги сценария:

  1. Начальный исходный код, который является релизом 1.0, регистрируется в TFS в ветви MAIN.
  2. Ветвь MAIN помечена V1.0.
  3. Ветвь DEV создается от ветви MAIN.
    от $/WoodGroveBanking/Main/ к $/WoodGroveBanking/DEV
  4. Ветвь DEV помечена V1.1 в начале разработки следующей версии.
  5. Для ветви MAIN периодически выполняется прямая интеграция в DEV.
  6. Ветвь DEV достигла определенных стандартов качества и для нее выполняется обратная интеграция в MAIN
    от $/WoodGroveBanking/DEV к $/WoodGroveBanking/Main/
  7. Ветвь MAIN помечается V1.1
  8. Ветвь DEV помечается V1.2 и разработка продолжается дальше.

Структура на Team Foundation Server

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

Рисунок 2. Структура в системе версионного контроля

Рисунок 3. Иерархия ветвей

Артефакты системы версионного контроля для сценария

Рисунок 4. Создание ветви от MAIN к DEV

Рисунок 5. Объединение от MAIN к DEV

Рисунок 6. Объединение от DEV к MAIN

Сценарий #2: Параллельная разработка исправлений, пакета обновлений и следующей версии

Рисунок 7. Параллельная разработка исправлений, пакета обновлений и следующей версии

Описание сценария: Параллельная разработка исправлений, пакета обновлений и следующей версии

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

У команды разработки Windows в Microsoft есть общая структура ветвления, которая обеспечивает возможность одновременно вести работу над исправлениями, пакетами обновления и разработку будущих релизов. У команды разработки Windows есть план ветвления, который точно определяет пути, как код покидает организацию и переходит к клиентам. Если говорить проще, то ветви для Windows включают минимум 3 различных поставки релиза:

  • Главный релиз – Major Release (RTM)
  • Исправления (Hot Fixes) для главного релиза
  • Пакеты обновления (Service Packs) для Главного Релиза

В пределах каждого из этих 3 поставок релиза есть отдельные планы ветвления, которые позволяют один раз зарегистрировать изменения и далее объединять их с главным релизом. От ветви разработки до главной ветви должны регулярно выполняться прямая (от родителя к дочерней ветви) и обратная (от дочерней к родительской ветви) интеграции. Регулярные прямая и обратная интеграции гарантируют, что вся организация понимает сущность структурирования приложения и знает о сути различий между усилиями по разработке. Когда код в главной ветви достигает определенного качества релиза (например, количество ошибок, % прохождения тестов, отзывы об использовании, и т.д.), то создается ветвь выпуска/релиза для этого релиза. Ключевой момент этого плана ветвления это то, что ветви пакета обновлений, исправлений и RTM создаются в таком же порядке, чтобы гарантировать нормальную взаимосвязь между родительскими и дочерними ветвями. Не имея целостности этих связей между ветвями, организация не сможет решать проблемы с регрессией или конфликтами слияния.

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

Определения ветвей для этого сценария:

  • DEV – дочерние ветви главного потока, где разработчики работают над будущими версиями продукта.
  • Hot Fix – определенные исправления, необходимые для решения проблем определенного заказчика.
  • Main – это соединяющая ветвь между разработкой и ветвью выпусков. Для большинства организаций эта ветвь должна быть очень стабильна.
  • Production – дочерние ветви главного потока, которые содержат изменения по сопровождению (т.е. исправления и пакет обновления).
  • RTM – релиз, который передается заказчику, эта ветвь содержит исходные коды для конечного релиза.
  • Service Pack – общий пакет текущих исправлений и обновлений, предназначенный для ранее поставленной версии продукта.
  • V-next – следующая версия продукта.

Шаги сценария:

  1. Начальный исходный код регистрируется на TFS в ветви [Main].
  2. Ветвь Dev создается с соответствующими ветвями для отдельных команд от [Main].
    1. Первая ветвь: $/WoodGroveBanking/Dev/Dev_Team1
    2. Вторая ветвь: $/WoodGroveBanking/Dev/Dev_Team2
  3. Организации необходимо создать пакет обновления для приложения, набор исправлений ошибок, поэтому создается ветвь Service Pack под ветвью Production.
    от $/WoodGroveBanking/Main/ к $/WoodGroveBanking/Production/V1/ServicePack
  4. Организация должна иметь возможность отправлять отдельные исправления и иметь возможность интегрировать все исправления в следующий общий релиз без проблем с регрессией, поэтому дочерняя ветвь для Hot Fix создается под Service Pack.
    от $/WoodGroveBanking/Production/V1/ServicePack к $/WoodGroveBanking/Production/V1/Hot Fix
  5. Организация хочет при достижении некоторой объективных целей создавать ветвь релиза, поэтому дочерняя ветвь для версии RTM создается от Hot Fix.
    от $/WoodGroveBanking/Production/V1/Hot Fix к $/WoodGroveBanking/Production/V1/RTM
  6. Организация также начала работу над следующей версией продукта V2, поэтому дочернюю ветвь необходимо создать от Main для V2.
    от $/WoodGroveBanking/Main/ к $/WoodGroveBanking/Production/V2/ServicePack
  7. Организация понимает, что после выпуска версии V2, через некоторое время будет формироваться пакет обновлений, который будет содержать все текущие исправления, поэтому структура ветвей будет идентична как и для V1 и дочерняя ветвь для Hot Fix создается под Service Pack.
    от $/WoodGroveBanking/Production/V1/ServicePack к $/WoodGroveBanking/Production/V2/Hot Fix
  8. Выпуск версии V2 займет много времени на разработку и проверку, но когда-то в будущем будет создана дочерняя ветвь для версии RTM от ветви Hot Fix.
    от $/WoodGroveBanking/Production/V1/Hot Fix к $/WoodGroveBanking/Production/V2/RTM

Структура на Team Foundation Server

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

Рисунок 8. Структура в системе версионного контроля

Рисунок 9. Иерархия ветвей

Артефакты системы версионного контроля для сценария

Этот раздел объясняет связь между артефактами системы версионного контроля при реализации этого сценария на Team Foundation Server.

Рисунок 10. Ветвь для Dev_Team1

Рисунок 11. Ветвь для V1 Service Pack

Рисунок 12. Ветвь для V1 Hot Fix

Рисунок 13. Ветвь для V1 RTM

Рисунок 14. Ветвь V2 Service Pack

Важные моменты сценария:

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

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

Любые изменения для релиза V1 выполненные в соответствующих ветвях, основаны на следующих критериях.

  • Исправление ошибок, влияющих на поставку, для v1 RTM – регистрируется в production/V1/RTM
  • Ветвь RTM устанавливается в режим только для чтения после релиза.
  • Исправления для выпуска V1 – регистрируются в production/V1/Hot Fix
  • Изменения для SP 1 – регистрируются в production/V1/Service Pack
  • Изменения для V2 – регистрируются в ветви разработки

Для изменений должна применяться обратная интеграция только по пути RTM-> HF-> SP-> Main. Это гарантирует, что будущие релизы не столкнуться с регрессиями, поскольку исправления интегрируются в следующий общий релиз (т.е. все исправления будут объединены в следующий пакет обновления). Не делайте прямых интеграций от главной до ветки пакета обновления после инициации ветвей релиза. Исключением могут быть определенные изменения, которые необходимы для выпуска исправлений или пакета обновления.

Сценарий #3: Сценарий использования ветвлений и меток

Рисунок 15. Сценарий использования ветвлений и меток

Описание сценария: Ветвление от меток

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

Метки в Team Foundation Server – это мощный инструмент, который позволяет команде разработки быстро идентифицировать файлы на определенном уровне версий. Использование меток как часть стратегии ветвления позволяет разработчикам изолировать код от последующих изменений, которые, возможно, будут выполняться в системе управления версиями. Например, если необходима будет поддержка определенной версии, то ветвь может быть создана в любое время на основе метки. Это позволяет иметь более простую файловую структуру в системе управления версиями, т.к. новые папки можно создавать только тогда, когда это необходимо.

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

Определения ветвей для этого сценария:

  • Dev – дочерние ветви от главной, где разработчики выполняют разработку следующей версии продукта.
  • Main – это соединение между разработкой и ветвями выпуска. Для большинства организаций эта ветвь должна быть очень стабильна.
  • Production – дочерние ветви главного потока, которые содержат изменения по сопровождению (т.е. исправления и пакет обновления).
  • Test – где группа проверки качества выполняет тестирование приложения на различных внутренних релизах.

Шаги сценария:

  1. Начальный исходный код регистрируется в TFS в ветви [Main]
  2. Ветви Dev создаются с соответствующими ветвями для команд разработки от [Main].
    1. Первая ветвь: $/WoodGroveBanking/Dev/Dev_Team1
    2. Вторая ветвь: $/WoodGroveBanking/Dev/Dev_Team2
  3. Команда Team1 достигает первую веху и применяет метку V1.1 на исходный код своей ветви Dev_Team1
  4. Команда Team2 достигает вторую веху и применяет метку V1.2 на исходный код своей ветви Dev_Team2
  5. Dev_Team1 формирует ветку Test на основе метки, чтобы позволить команде QA проверить результаты работы.
    Формирование ветви на основе метки V1.1 от $/WoodGroveBanking/Dev/Dev_Team1 к $/WoodGroveBanking/Test/V1.1
  6. Dev_Team2 формирует ветку Test на основе метки, чтобы позволить команде QA проверить результаты работы.
    Формирование ветви на основе метки V.1.2 от $/WoodGroveBanking/Dev/Dev_Team2
    к
    $/WoodGroveBanking/Test/V1.2

Структура на Team Foundation Server

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

Рисунок 16. Структура в системе версионного контроля

Рисунок 17. Иерархия ветвей

Артефакты системы версионного контроля для сценария

Этот раздел объясняет связь между артефактами системы версионного контроля при реализации этого сценария на Team Foundation Server.

Рисунок 18. Dev_Team1 поиск метки V1.1

Рисунок 19. Формирование ветки тестирования Dev_Team1 по метки V1.1

Рисунок 20. Формирование ветки тестирования Dev_Team2 по метки V1.2

Важные моменты сценария:

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

Важные моменты, предостерегающие от злоупотребления метками:

  1. Team Foundation Server не сохраняет историю изменений для метки.
  2. Учитывая определенные разрешения, метки могут быть удалены или изменены, при этом нет никакого пути просмотра этих изменений.
  3. Могут быть конфликты в содержании метки, если несколько человек хотят использовать одну метку, изменять ее или изменять файлы, содержащиеся в метке.
  4. Исходя из этого, метки должны использоваться только в случаях, когда необходимо иметь «снимок» исходного кода и когда можно гарантировать через разрешения, что метка не будет изменена.

Соглашения по среде и расположению сборки для сценариев

ВАЖНОЕ ПРИМЕЧАНИЕ: Сборочные скрипты (т.е. TeamBuildTypes), должны считаться первоочередными артефактами и должны быть изолированы от всех других веток в дереве проводника системы версионного контроля. Они должны быть изолированы от фактического исходного текста, предпочтительно в каталоге, который находится рядом с каталогом с исходным кодом выбранной ветви. Например, в основном потоке могут быть и $/WoodGrooveBanking/Main/source и $/WoodGrooveBanking/Main/build. Поскольку ветви порождаются от главного потока, сборочные скрипты перейдут вместе с исходным кодом с сохранением относительных путей независимо от ветви.

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

  • Development – среда, где ведется вся разработка. Это самая изменчивая среда, т.к. все изменения выполняются в этой среде. Среда разработки должна отражать последнюю версию программного обеспечения, которое стабильно и доступно в ветви MAIN.
  • Test – все тесты выполняются тестерами в этой среде. Обычно только устойчивые сборки (обычно каждые две недели) поставляются в тестовую среду, что позволяет команде разработки сосредоточиться на достижении тестируемого состояния перед передачей в тестовую среду.
  • User Acceptance Testing (UAT) – среда UAT более устойчива чем Dev или Test. Часто используется для проведения демонстраций и является средой, которая используется заинтересованными лицами для тестирования программного обеспечения перед сдачей.
  • Staging/Pre-Production – Не все организации используют эту среду, потому что стоимость аппаратного обеспечения для этой среды может быть высокой. У среды Staging/Pre-Production должно быть аппаратное обеспечение идентичное или очень похожее к промышленной среде, чтобы проблемы, которые могут проявиться в промышленной среде, были обнаружены заранее (например, проблемы кластеризации базы данных, проблемы Web-кластеров, проблемы сетевых брандмауэров и т.д.)
  • Production – среда, которая поддерживает промышленное использование приложения.
  • Maintenance – после того как приложение выпущено и команда разработки продолжает разрабатывать следующую главную версию приложения или продукта, среда обслуживания используется для проверки исправлений и изменений, выполненных в поддерживаемой версии.

Соответствие структуры ветвей и среды

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

Среда Ветвь Заметки
Development DEV Обычно среда Development отображает последнюю хорошую сборку из ветви DEV
Test Обычно MAIN, иногда ветвь DEV Обычно среда тестирования будет содержать сборку программного обеспечения от MAIN. Среда тестирования иногда также может содержать сборки из ветви DEV.
UAT Обычно MAIN, иногда PRODUCTION, когда необходимый релиз должен быть передан на приемочное тестирование пользователям Чаще среда UAT должна использовать высококачественные сборки из MAIN.
Staging/Pre-Production PRODUCTION Pre-Production обычно должна использовать сборки из PRODUCTION
Production PRODUCTION Production всегда включает сборки из PRODUCTION

<<Назад

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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