Ветвь стратегически

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Как ваша команда управляет кодом во время одновременного внесения нескольких изменений с помощью нескольких выпусков проекта?

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

Дополнительные сведения о создании и слиянии ветвей кода см. на следующей странице на веб-сайте CodePlex: Руководство по ветви Team Foundation Server 2.0.

Ветвление и объединение влечет за собой следующие принципы:

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

2. Ветвь MAIN должна содержать код, прошедший тесты интеграции, чтобы он всегда готов к выпуску.

3. Ветвь DEVELOPMENT (или work) постоянно развивается, так как члены команды проверка периодически меняются.

4. Метки — это моментальные снимки файлов в ветви в определенное время.

   Дополнительные сведения см. в разделе "Использование меток для создания моментального снимка файлов".

Team Foundation Build позволяет выбрать один из нескольких типов сборок для ваших ветвей: вручную, непрерывной, воротной, последовательной и запланированной. Рекомендуется, чтобы ветвь MAIN была введена проверка типа сборки. Это означает, что ветвь DEVELOPMENT должна передавать все требования к основной ветви, прежде чем можно зафиксировать обратную интеграцию. Ветвь DEVELOPMENT должна запускать непрерывный тип сборки, так как команда должна знать как можно скорее, когда новая проверка влияет на ветвь DEVELOPMENT.

Насколько часто ваша команда должна выполнять обратную интеграцию и переадресацию?

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

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

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

Как ваша команда управляет источниками, реализующими различные истории пользователей?

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

Когда команда должна добавить ветвь?

В следующих ситуациях следует создать ветви:

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

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

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

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

Как команда управляет выпусками с точки зрения управления версиями?

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

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

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

Связанные статьи

• Выбор эффективной стратегии ветвления