Есть ли способ настроить это с помощью политик филиала? Если нет, есть ли другая альтернатива?
Azure Devops не имеет возможности контролировать, какую ветвь можно объединить с главной, но мы можем использовать политики ветвей в качестве обходного пути. Вот мое рабочее направление:
Step1 . Создайте простой конвейер (неважно, classi c или yaml, но classi c больше подходит для этого сценария) с одной командной строкой задача:
script: Тест ThisIsNotDevBranch.exe
fail on standard error: 
condition when run the task: 
Формат Yaml:
steps:
- script: 'ThisIsNotDevBranch.exe test'
failOnStderr: true
displayName: 'Command Line Script'
condition: ne(variables['System.PullRequest.SourceBranch'], 'refs/heads/dev')
Step2 . Настроить master ветку политику ветки , добавить политику сборки с настройкой ниже:
Выберите созданный конвейер на шаге 1 как тот, который будет использоваться в политике сборки.
Как это работает:
1. Каждый раз, когда я создаю запрос Pull для объединения одной ветви в мастер, конвейер, созданный на шаге 1, будет запущен автоматически.
2.Я использовал команду, которой на самом деле не существует в задаче CMD, и установил флажок Fail On Standard Error. Затем эта задача выдаст ошибку и не выполнит задачу, конвейер, если она будет запущена.
3. При условии в этой задаче эта задача будет выполняться, только если исходная ветка PR является dev ветвь (refs/heads/dev).
4. Теперь, если я создаю PR для слияния ветки testBranch в master => конвейер запуска => пользовательское условие = true => задача будет выполняться, а затем выбрасывается ошибка при сбое конвейера => тогда PR не может быть завершен (кнопка PR в PR не может работать, если конвейер не работает).
Тогда, если я создаю PR для объединения ветки dev в master => конвейерный запуск => условие = false => задача будет пропущена => конвейер завершится успешно>> мы можем утвердить и завершить PR.
Примечание:
1.Если вы хотите установить только ветку dev, можно объединиться с master, затем используйте refs/heads/dev в условии. Если это Dev, вместо этого используйте refs/heads/Dev.
2. Ядром этого направления является условная задача CMD, мы можем заменить ее другой задачей. Кроме того, нам не нужно создавать конвейер для запуска задачи. Если хотите, просто добавьте условную задачу в существующий конвейер. Однако для определения guish необходимы дополнительные шаги, независимо от того, запущен ли конвейер PR или обычными обновленными исходными файлами. Поэтому я рекомендую создать новый простой конвейер classi c для проверки.
Кроме того:
1.Детали о System.PullRequest.SourceBranch .
2. Отступить от политики сборки Вы также можете попробовать другие политики в политиках веток для проецирования вашей главной ветки. Как сказал Krzysztof Madej , вы также можете рассмотреть возможность проверки кода. Сочетание этих вариантов политики - хороший выбор!