Управление выполнением конвейеров с помощью триггеров
Теперь у вас есть рабочий конвейер, который развертывает файл Bicep в среде Azure. Однако при каждом изменении файлов вы запускаете конвейер вручную. В этом уроке вы узнаете, как автоматически запускать конвейер при изменении кода Bicep.
Примечание.
Команды в этом уроке демонстрируют основные понятия. На этом этапе не выполняйте команды. Вскоре вы поупражняетесь с полученными знаниями.
Что такое триггер конвейера?
Триггер конвейера — это условие, при достижении которого ваш конвейер автоматически запускается на основе созданных правил. Триггеры можно настроить для выполнения конвейера через запланированные интервалы. Их также можно настроить для запуска конвейера при каждом изменении файлов в репозитории. Рекомендуется применять второй вариант, так как это позволяет выполнять все тесты и шаги развертывания после каждого изменения кода.
Если вы не используете автоматический триггер, кто-то может внести изменения в файл Bicep и даже зафиксировать его и отправить в репозиторий. Если кто-то забывает выполнить конвейер, определения ресурсов в файле Bicep и ресурсов, разворачиваемых в среде Azure, будут отличаться. Предположим, что несколько фиксаций и отправок кода уже сделаны, но еще не развернуты. Если в ходе одного из этих изменений кто-то допускает ошибку или задает неверную конфигурацию файла Bicep, эту ошибку будет сложно отследить, так как для этого придется проанализировать несколько фиксаций, которые будут развернуты вместе. Через некоторое время вы не сможете быть уверенными в том, что ваш код Bicep действительно представляет вашу инфраструктуру, и его ценность будет постепенно снижаться.
Если конвейер настроен на запуск при каждом обновлении файлов, его выполнение будет начинаться в момент отправки изменений. Вы сразу понимаете, допустимы ли ваши изменения, и гарантируете актуальность рабочей среды.
Триггеры ветви
Распространенным типом триггера является триггер ветви, который иногда называют триггером непрерывной интеграции или триггером CI. При его использовании конвейер выполняется при каждом внесении изменений в указанную ветвь. Если вы фиксируете и отправляете изменение в другую ветвь, конвейер не активируется и он не запускается. Обычно этот тип триггера задается для ветви по умолчанию или главной ветви. Для этого используется следующий код:
trigger:
- main
Активация при изменении нескольких ветвей
Можно настроить триггеры для выполнения конвейера в определенной ветви или в наборах ветвей. Например, предположим, что вы создаете ветви выпуска, содержащие код, который вы будете развертывать для конкретного выпуска проекта. Можно использовать имена ветвей, такие как release/v1, release/v2 и т. д. Вы хотите, чтобы ваш конвейер выполнялся при каждом изменении кода в ветви, имя которой начинается с release/. Свойство include можно использовать в сочетании с подстановочным знаком *:
trigger:
branches:
include:
- main
- release/*
Также можно исключить определенные ветви. Предположим, вы работаете над проектом совместно с членами группы. Ваши коллеги создают ветви возможностей, чтобы проверить свои идеи в файлах Bicep. У всех ветвей возможностей имена наподобие feature/add-database, feature/improve-performance и т. д. Вам требуется, чтобы конвейер автоматически выполнялся во всех ветвях, за исключением ветвей возможностей, создаваемых вашими коллегами. С помощью свойства exclude вы гарантируете, что конвейер не будет автоматически активироваться для изменений в ветвях возможностей:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Совет
Обратите внимание на кавычки вокруг подстановочного знака в фильтре include. Формат файла YAML требует заключать один символ * в кавычки при его использовании в качестве подстановочного знака.
Фильтры путей
Иногда в репозитории есть файлы, которые не связаны с развертыванием. Например, в репозитории может быть папка deploy, содержащая код Bicep, а также отдельная папка docs, содержащая файлы документации. Вы хотите активировать конвейер, когда кто-либо вносит изменения в любой из файлов Bicep в папке deploy, но вы не хотите запускать конвейер, если кто-то изменяет файл документации. Чтобы настроить триггер для реагирования на изменения в определенной папке в репозитории, можно использовать фильтр пути:
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
Если кто-то зафиксирует изменение, которое обновляет только файл документации, конвейер не будет выполняться. Но если пользователь изменяет только файл Bicep или даже файл Bicep в дополнение к файлу документации, то триггер запустит конвейер.
Создание расписания для автоматического выполнения конвейера
Вы можете запускать конвейер по определенному расписанию, а не в ответ на изменение файла. Например, вы можете запустить ночную версию кода Bicep или автоматически развертывать тестовую среду каждую утро. Используйте ключевое слово schedules вместо trigger и задайте периодичность с помощью выражения cron:
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Примечание.
Выражение cron — это специально отформатированная последовательность символов, указывающая, как часто должно происходить какое-то действие. В этом примере 0 0 * * * означает ежедневное выполнение в полночь по Гринвичу.
Для запланированного события также можно задать ветвь репозитория. При запуске конвейера используется последняя версия кода из ветви, заданной в расписании.
Использование нескольких триггеров
Можно сочетать триггеры и расписания, как показано в следующем примере:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
При создании триггера ветви и запланированного триггера в одном конвейере конвейер выполняется каждый раз, когда файл изменяется в ветви, заданной в триггере и в заданном расписании. В этом примере конвейер выполняется ежедневно в полночь по Гринвичу (UTC), а также каждый раз, когда в главную ветвь отправляется изменение.
Совет
Рекомендуется указывать триггеры для каждого конвейера. Если этого не сделать, то по умолчанию ваш конвейер будет автоматически выполняться при каждом изменении любых файлов в любой ветви, что не всегда необходимо.
Управление параллелизмом
По умолчанию Azure Pipelines позволяет одновременно выполнять несколько экземпляров конвейера. Это может произойти при выполнении нескольких фиксаций в ветвь за короткое время.
В некоторых ситуациях наличие нескольких параллельно выполняющихся экземпляров конвейера не является проблемой. Однако при работе с конвейерами развертывания может оказаться непросто убедиться в том, что ваш конвейер не перезапишет ресурсы или конфигурацию Azure непредвиденным образом.
Чтобы избежать этих проблем, можно использовать ключевое слово batch с триггером, как в следующем примере:
trigger:
batch: true
branches:
include:
- main
При активации триггера служба Azure Pipelines гарантированно ожидает завершения любого активного выполняемого экземпляра конвейера. Затем она выполняет новый экземпляр со всеми изменениями, накопленными с момента последнего выполнения.