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

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

Создание ветвей для репозиториев система управления версиями Team Foundation (TFVC) полезно для изоляции риска. Рассмотрим некоторые проблемы, с которыми обычно сталкиваются члены группы, когда они работают над проектом программного обеспечения, который работает более чем на пять или десять человек:

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

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

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

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

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

Только основной

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

РИСК: изменчивость и отсутствие истории с метками TFVC может добавить риск управления изменениями.

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

Изоляция разработки

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

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

ПРИМЕЧАНИЕ. С этой стратегией команды, скорее всего, сохранят ветвь разработки навсегда, потенциально создавая большой журнал билетов слияния.

Изоляция компонентов

Изоляция функций — это специальная производная изоляция разработки, которая позволяет ветвить одну или несколько ветвей компонентов из основной, как показано выше, или из ветвей разработки.

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

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

Изоляция выпуска

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

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

Никогда не пересылайте интеграцию (FI) из main. Блокировка ветвей выпуска с помощью разрешений доступа, чтобы предотвратить непредвиденные изменения в выпуске. Исправления и исправления, внесенные в ветвь выпуска, могут быть обратно интегрированы (RI) обратно в основную ветвь.

ПРИМЕЧАНИЕ. Ни один из сценариев ветвления неизменяем, поэтому вы заметили, что исправления для аварийного реагирования выполняются в ветвях выпуска. Развивайте каждую стратегию в соответствии с вашими требованиями, не теряя видимость сложности и связанной стоимости.

Изоляция обслуживания и выпуска

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

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

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

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

Обслуживание, исправление, изоляция выпуска

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

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

Q&A

Почему ветви должны быть короткими?

Сохраняя ветви кратковременными, конфликт слияния хранятся как можно меньше.

Почему только ветвь при необходимости?

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

Зачем удалять ветви?

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

Может ли база кода быть ветвленной в проектах?

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

Что касается стратегии продвижения кода?

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

При слиянии dev с основной ветвью почему не обнаружены изменения?

Скорее всего, вы проигнорировали изменения в предыдущих слияниях, например с помощью keep source параметра разрешения конфликтов. Дополнительные сведения см . в разделе слиянием ветви разработки с главной: не было изменений для слияния .

Существуют ли сходства между стратегиями филиалов TFVC и Git?

Стратегия ветвления функций TFVC аналогична ветвям раздела Git.

Авторы: Джесси Хоуинг, Маркус Фернандес, Майк Фуди и Вилли Шауб из ALM | DevOps Rangers. Вы можете связаться с ними здесь.

(c) Корпорация Майкрософт 2015 г. Все права защищены. Этот документ предоставляется как есть. Сведения и представления, выраженные в этом документе, включая URL-адрес и другие ссылки на веб-сайт Интернета, могут изменяться без уведомления. Вы берете на себя все риски, связанные с использованием сведений, приводящихся в данном документе.

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