Триггерная сборка для PR, но предотвращение CD до завершения PR - PullRequest
0 голосов
/ 25 октября 2019

Моя команда и я изо всех сил пытаемся реализовать определенный шаблон CI / CD в ADO.

Мы определили конвейер сборки под названием "Разработка" и конвейер выпуска с тем же именем. Мы установили Политику сборки в нашей ветке разработки, которая требует успешной сборки конвейера сборки до завершения PR. У нас также есть политики для проверок / одобрений, разрешения комментариев и связанных рабочих элементов.

Как и ожидалось, когда поднимается PR, сборка, на которую ссылается наша политика, запускается. Также, как и ожидалось, PR не может быть завершен, пока эта сборка не будет успешной. Однако проблема, с которой мы столкнулись, заключалась в том, что из-за того, что у нас был установлен триггер CD в Release Pipeline, артефакты, сгенерированные сборкой, запускаемой PR, будут всегда развернутыми, независимо от состояния остальныхполитики PR.

Последовательность, которую мы хотим получить, такова:

  1. Повышение PR приводит к выполнению нашего конвейера сборки "Develop".
    • Эта сборка должна быть успешной до того, как PR может быть завершен.
    • Артефакты этой сборки сохраняются таким образом, что конвейер сборки не должен запускаться снова после завершения PR, просто чтобы выполнить развертывание. (сборка занимает некоторое время).
  2. Конвейер сборки успешно выполняется.
    • PR по-прежнему не может быть завершен, пока не будут выполнены другие политики.
  3. Остальные политики филиала удовлетворены.
  4. PR завершен.
    • Только теперь могут быть развернуты артефакты, сгенерированные из конвейера сборки.
  5. Выпущен конвейер выпуска "Разработка", который развертывает артефакты в нашей среде тестирования.

После того, как я поигрался с вариантами наших конвейеров, я попытался просто установить «Триггер запроса на извлечение» вместо «Триггера непрерывного развертывания» в конвейере освобождения. Я предполагал, что это потребует, чтобы PR привел к созданию артефактов, и PR завершен. Мое предположение было неверным. С помощью этой новой настройки повышение PR запускает конвейер сборки, а успешное выполнение конвейера сборки запускает конвейер выпуска, даже если PR еще не завершен.

Наш конвейер сборки создает решение, проводит тесты,запускает некоторые сценарии PowerShell и, наконец, публикует артефакты в конвейеры Azure. Возможно, это делает слишком много. Возможно, есть какой-то способ построить, запустить тесты и сценарии, а затем каким-то образом подождать, пока PR завершится, прежде чем передавать артефакты в Release Pipeline. Я просто не могу понять это. Есть ли способ выполнить последовательность, которую я перечислил выше?

Требования, в двух словах:

  • Сборка должна начаться, как только будет повышен PR.
  • Сборка не должна выполняться более одного раза (это занимает много времени, и мы не можем ждать двух сборок только для того, чтобы соответствовать политике сборки перед «реальной» сборкой).
  • Завершение PRдолжен вызвать освобождение конвейера.

1 Ответ

1 голос
/ 25 октября 2019

В вашем описании есть некоторое недопонимание триггера PR.

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

Триггеры пул-запроса

Однако для триггеров CD вы могли бы добавить фильтры веток сборки , если вы хотите создать выпуск только тогда, когда сборка производится путем компиляции кода из определенных ветвей (применимо только тогда, когда код находится в репозитории TFVC, Git или GitHub) или когда сборкаимеет определенные теги. Это могут быть как фильтры включения, так и исключения. Например, используйте функции / *, чтобы включить все сборки в ветку компонентов. Вы также можете включить пользовательские переменные в значение фильтра.

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

Более подробно, пожалуйста, посмотрите ответ Джеффа Шеплера в этом подобномвопрос: триггер сборки VLLS Release Pull

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