Как в Azure DevOps Server 2019 объединить главную ветвь с ветвью разработки БЕЗ применения ее политик?

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

Когда меня устраивает предварительная версия, я создаю дополнительный PR для слияния develop с master, что, в свою очередь, вызывает запуск сборки компакт-диска, что приводит к производственному выпуску пакета NuGet.

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

Дело в том, что после этого я хочу снова объединить мастер с разработкой, которая прямо сейчас создает новую предварительную версию (что на данный момент не имеет значения).

Есть ли у меня способ сообщить Azure DevOps, что в особом случае, когда мастер снова объединяется с разработкой, политики ветвления следует пропускать? Я вообще должен делать PR от мастера к разработке, когда на самом деле все, что я хочу сделать, это объединить ранее утвержденный PR от исправления к мастеру !?

Любые советы приветствуются.


person Crono    schedule 25.06.2019    source источник
comment
Для человека, который проголосовал за то, чтобы это было слишком широко, вы можете посоветовать, как сделать вопрос более конкретным, чем то, как пропустить политику ветвей при слиянии ветвей на сервере? Спасибо.   -  person Crono    schedule 26.06.2019


Ответы (1)


как я могу объединить основную ветвь с ветвью разработки БЕЗ применения ее политик?

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

Таким образом, нет такого нестандартного способа слияния основной ветки с ветвью разработки БЕЗ применения ее политик. В качестве обходного пути мы могли бы установить для параметра Bypass policies when completing pull requests значение Allow, Ветви-> Разработка-> Безопасность веток:

введите здесь описание изображения

С этими настройками указанный пользователь может объединить главную ветвь с ветвью разработки БЕЗ применения его политик.

Есть ли у меня способ сообщить Azure DevOps, что в особом случае, когда мастер снова объединяется с разработкой, политики ветвления следует пропускать?

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

Должен ли я даже делать PR от мастера для разработки, когда на самом деле все, что я хочу сделать, это объединить ранее утвержденный PR от исправления к мастеру !?

Краткий ответ: нет.

Приведу набросок:

введите здесь описание изображения

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

Затем нам нужно отодвинуть ветку master на develop. Вы хотите обойти политику ветвления на develop, потому что мы уже PR коммит hotfix, когда переходим к основной ветке, я прав?

Если да, это зависит от того, совпадают ли политики веток в master и develop ветвях (или выше), чтобы определить, нужно ли вам делать PR от мастера для разработки.

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

Подводя итог, когда мы устанавливаем ветвь master в качестве основной ветки, а ветвь master устанавливаем политики ветвления с наивысшей спецификацией, мы могли бы объединить master в develop ветвь без PR, когда на самом деле все, что я хочу сделать, это объединить ранее утвержденный PR от исправления к мастеру!

Надеюсь это поможет.

person Leo Liu-MSFT    schedule 27.06.2019
comment
Спасибо за помощь. Я понял, как много. Я просто надеялся, что для этого будет более упорядоченный процесс. Мне трудно поверить в то, что более крупные игроки отрасли, которые решили довериться Azure DevOps в качестве своего механизма CI / CD, на самом деле согласны с тем, как он работает. Я надеялся, что делаю что-то не так, и что будет гораздо лучший способ сделать что-то, но, увы, похоже, что это так. - person Crono; 01.07.2019