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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

У меня есть способ сообщить Azure DevOps, что в особом случае master при слиянии с разработчиком, отраслевые политики должны быть пропущено?

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

Должен ли я даже сделать пиар от мастера для развития, когда на самом деле все, что я Вы хотите объединить ранее одобренный 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 branch без PR, когда на самом деле все, что я хочу сделать, это объединить ранее одобренный PR с исправлениями в master!

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