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

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

Microsoft Visual Studio Team Foundation Server Branching Guidance 2010 Scenarios

<<Назад

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

TFS Branching Guidance Release 3.0, 12/19/2008

Scenarios

VSTS Rangers

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

TFS Branching Guidance – Scenarios

Bijan Javidi, James Pickell, Tina Erwee, Willy-Peter Schaub, Wayne Ewington, Bob Jacobs, Oliver Hilgers, Bill Heys

Microsoft Corporation

Оглавление

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

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

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

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

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

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

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

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

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

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

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

  • Ветвление исходного текста для создания стабильного изолированного рабочего пространства или вехи состояния исходного кода (например, последняя успешная сборка). В ходе ветвления источник, из которого код ветвится, называется родительской ветвью, а целевая ветвь (результирующая копия кода) – дочерняя ветвь.
  • В ветвях разработчики могут вносить изменения в код, который может содержаться (изолирован) и стабилизироваться отдельно от остальных ветвей.
  • Разработчики могут выполнять двунаправленную синхронизацию изменений между двумя потоками, которые связаны как родитель/дочерний поток. Слияние из родительского в дочерний поток называется прямой интеграцией. Слияние из дочернего в родительский поток называется обратной интеграцией. Иногда слияние может быть сделано между ветвями, которые не имеют связи для слияния (такие как родительский/дочерний поток). Такое слияние называется слияние без базовой версии. Слияние без базовой версии создает связь для слияния в будущем между исходным и целевым потоком.
  • Каждый из планов авторов ветвления начинается с ветви Main. Главный поток предназначен для хранения стабильного кода. Потоки разработки являются полными ответвлениями от главного.
  • Мы рекомендуем часто синхронизировать Главной поток с каждым дочерним потоком разработки. Это достигается за счет регулярного выполнения слияния прямой интеграции (FI) из ветви Main в ее дочерние ветви Development.
  • С другой стороны, мы рекомендуем выполнять только обратную интеграцию (объединение кода из дочерних Development ветвей обратно в поток Main), когда код в исходном потоке стабилен и прошел врата качества Обеспечения качества (QA).
  • Содержание ветви Main в синхронизации с ветвями Development помогает избежать проблем «большого взрыва» для слияния, когда много изменений с ветки Main объединяются в дочернюю ветвь Development и вызывают много конфликтов слияния, которые должны быть решены до завершения слияния.
  • Часто, когда вносятся изменения в файл в исходном потоке слияния, они могут быть автоматически объединены с соответствующим файлом в целевом потоке. Слияние конфликты возникают, когда были внесены изменения и тот же файл как в исходном так и в целевом потоке, участвующих в слиянии. Часто бывает, что эти изменения в различных разделах файла – эти конфликты слияния могут быть решены автоматически с помощью инструмента (AutoMerge). Иногда разработчик, выполняющий слияние, может знать, где переписать целевой файл (взять изменение из источника) или игнорировать источник (с сохранением целевой версии). Однако есть места, где разрешение конфликтов слияний требует ручного вмешательства. В таких ситуациях, TFS покажет окно с 3-емя способами разрешения конфликтов слияния, показывающее конфликтующие изменения. Пользователь может просматривать код в файле-источнике, целевом файле и результирующий объединенный файл. В Visual Studio ® 2010 разрешение конфликтов в настоящее время немодальная операция. Здесь пользователь может выбрать конкретные строки кода из целевого или исходного файла (или обоих), которые будут объединены в конечный результат.

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

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

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

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

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

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

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

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

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

Код из ветви MAIN должен часто объединяться (с прямой интеграцией – FI) в ветвь DEV. Это дает возможность изменениям, которые могли произойти в ветви MAIN, быть объединенными (интегрированными) с постоянной разработкой в ветви DEV.

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

В какой-то определенный момент времени, когда ветвь DEV соответствует определенным условиям качества (например, количество нерешенных ошибок), она готова быть передана в выпуск. На этот момент, ветвь DEV объединяется (с обратной интеграцией – RI) в ветвь MAIN. Обязательно перед слиянием (RI) DEV с MAIN должно быть выполнено одно окончательное объединение (FI) из MAIN в DEV. Цель этого состоит в том, чтобы протестировать интеграцию MAIN и DEV в ветви DEV, сохраняя MAIN максимально устойчивой.

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

  1. Создается папка MAIN и подпапка Src.
  2. Регистрируются эти изменения.
  3. Выбирается папка MAIN и преобразовывается в ветвь (File | Source Control | Branching and Merging | Convert Folder to Branch)
  4. Создается ветвь DEV из MAIN (File | Source Control | Branching and Merging | Branch)
  5. Первоначальный исходный код (например, для версии 1.0) регистрируется в TFS в ветви MAIN.
  6. Ветвь MAIN помечается V1.0.
  7. Ветвь DEV создается из ветви MAIN и помечается V1.1
    $/WoodGroveBanking/MAIN/ к $/WoodGroveBanking/DEV
  8. Ветвь MAIN регулярно объединяется (FI) в ветвь DEV.
  9. Некоторые стандарты качества были соблюдены и ветвь DEV обратно интегрируется в MAIN
    $/WoodGroveBanking/DEV к $/WoodGroveBanking/MAIN/
  10. Ветвь MAIN теперь помечается V1.1
  11. Ветвь DEV помечается V1.2 и разработка продолжается дальше.

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

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

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

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

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

Рисунок 4. Конвертирование папки MAIN в ветвь

Рисунок 5. Ветвление DEV в MAIN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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, в виде структуры в системе версионного контроля и структуры ветвей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 17. Свойства ветви

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

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

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

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

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

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

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

  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, в виде структуры в системе версионного контроля и структуры ветвей.

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

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

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

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

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

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

Рисунок 22. Формирование ветки тестирования 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 такие блоггеры, как: