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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стратегия создания изолированных веток для разработчиков

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

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

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

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

стратегия

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

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

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

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

стратегия ветвления изоляции выпуска

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

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

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

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

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

стратегия ветвления изолированного выпуска службы

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

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

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

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

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

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

Q&A

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

Сохраняя ветви короткоживущими, конфликты при слиянии сводятся к минимуму.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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