Как управлять сборками валидации PR для более 100 проектов

Question

У нас есть более 100 сервисов / приложений в хранилище в Azure Devops. Мы определили один многоступенчатый конвейер CI / CD YAML для каждого (сборка и развертывание). Это ограничивает радиус взрыва и позволяет проверять каждую версию каждого проекта. Мы полагаемся на шаблоны для всей реальной работы конвейера, поэтому ее легко поддерживать;просто небольшой корневой файл azure-pipelines.yml для каждого проекта, который включает в себя необходимые шаблоны.

Теперь мы хотели бы начать использовать сборки проверки PR. И, насколько я могу судить, у нас есть два варианта:

1. Создание отдельной PR-сборки для каждого проекта и использование UI / API для политик для создания более 100 политик
2. Создайте одну PR-сборку, которая имеет этапы для всех 100+ проектов.

Я не фанат 1-го варианта, так как теперь у нас будет более 200 сборок. Второй вариант возможен, но чтобы избежать трехчасовой PR-сборки, нам нужен способ запуска только необходимых этапов (или сборок проекта).

Есть ли третий вариант, который мне не хватает? Если 2-й вариант - наша лучшая ставка, как отключить этапы для проектов, не измененных в этом PR (то есть, какое условие мы бы использовали)?

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

Answer 1

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

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

Итак, я предлагаю вам и вашим разработчикам команды ввести информацию project name в ваше сообщение о коммите. Затем в конвейере сборки вы можете использовать переменную Build.SourceVersionMessage, чтобы получить сообщение с комментарием. Поскольку это переменная среды, которая только работает на уровень шага (не работает для уровень стадии и уровень задания ), она требуетВы добавляете одну задачу на первом этапе и используете условие для нее.

Логика этого заключается в добавлении одного шага в качестве первого на каждом этапе. Этот шаг используется только для условного суждения. Если Build.SourceVersionMessage соответствует префиксу или любому ключевому слову, задания будут досрочно завершены.

Если использовать условие, подобное следующему:

condition: startsWith(variables['Build.SourceVersionMessage'], '[maven-plugin]')

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

Другое условиеможет для вас рассмотреть это:

condition: in(variables['Build.SourceVersionMessage'], 'maven-plugin')

Это не требует строгого формата записи контента, но также необходимо ввести имя проекта в сообщении фиксации. Таким образом, его можно оценить в рабочем состоянии с помощью приведенного выше сценария.

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