Определение утверждений и проверок

Azure DevOps Services

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

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

Этап может состоять из нескольких заданий, и каждое задание может использовать несколько ресурсов. Перед началом выполнения этапа все проверки всех ресурсов, используемых на этом этапе, должны быть удовлетворены. Azure Pipelines приостанавливает выполнение конвейера до каждого этапа и ожидает завершения всех ожидающих проверок. Проверки повторно проверяются на основе интервала повторных попыток, указанного в каждой проверке. Если все проверки не будут успешными до указанного времени ожидания , то этот этап не выполняется. Если какая-либо из проверок завершается сбоем (например, если отклонить утверждение для одного из ресурсов), этот этап не выполняется.

Утверждения и другие проверки не определены в yaml-файле. Пользователи, изменяющие файл yaml конвейера, не могут изменять проверки, выполненные до начала этапа. Администраторы ресурсов управляют проверками с помощью веб-интерфейса Azure Pipelines.

Важно!

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

Подключения к службе не могут быть указаны переменной.

Утверждения

Вы можете вручную управлять выполнением этапа с помощью проверок утверждения. Обычно это используется для управления развертываниями в рабочих средах.

  1. В проекте Azure DevOps перейдите к ресурсу (например, среде), которую необходимо защитить.

  2. Перейдите в раздел утверждения и проверки для ресурса.

Утверждения и проверки среды.

  1. Нажмите кнопку "Создать", укажите утверждающих и необязательное сообщение и нажмите кнопку "Создать ", чтобы завершить проверку утверждения вручную.

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

С помощью дополнительных параметров можно настроить минимальное число утверждающих, чтобы завершить утверждение. Группа считается одним утверждающего.

Вы также можете ограничить пользователя, который запрашивал (инициировал или создал) выполнение после завершения утверждения. Этот параметр обычно используется для разделения ролей среди пользователей.

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

Управление ветвью

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

Чтобы определить проверку элемента управления ветвью, выполните следующие действия.

  1. В проекте Azure DevOps перейдите к ресурсу (например, среде), которую необходимо защитить.

  2. Перейдите в раздел утверждения и проверки для ресурса.

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

Настройка проверки управления ветвью.

Во время выполнения проверка проверит ветви для всех связанных ресурсов в запуске в списке разрешенных. Если какая-либо из ветвей не соответствует критериям, проверка завершается ошибкой, и этап помечается сбоем.

Примечание

Для проверки требуется, чтобы имена ветвей были полны. Убедитесь, что формат имени ветви имеет значение refs/heads/<branch name>

Рабочие часы

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

Настройка проверки рабочих часов.

Если выполнение этапа не началось в конце рабочих часов (до некоторой другой проверки), утверждение рабочих часов автоматически отозвано, а на следующий день запланировано повторное вычисление. Проверка завершается ошибкой, если выполнение этапа не запускается в течение периода ожидания , указанного для проверки, и этап помечается сбоем.

Вызов функции Azure

Функции Azure — это бессерверная платформа вычислений, предлагаемая Azure. С помощью функций Azure можно выполнять небольшие фрагменты кода (называемые "функциями"), не беспокоясь о инфраструктуре приложений. Благодаря высокой гибкости функции Azure предоставляют отличный способ создания собственных проверок. Вы включаете логику функции проверки в Azure, чтобы каждое выполнение было активировано по http-запросу, имеет короткое время выполнения и возвращает ответ. При определении проверки можно проанализировать текст ответа, чтобы определить, успешно ли выполнена проверка. Оценка может повторяться периодически с помощью параметра времени между параметрами оценки в параметрах управления. Подробнее

Настройка проверки функции Azure.

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

Примечание

Определяемые пользователем переменные конвейера не имеют доступа к проверке. Доступ к предопределенным переменным и переменным можно получить только из связанной группы переменных в тексте запроса.

Вызов REST API

Вызов проверки REST API позволяет интегрироваться с любыми существующими службами. Периодически выполняйте вызов к REST API и продолжайте, если он возвращает успешный ответ. Подробнее

Оценка может повторяться периодически с помощью параметра времени между параметрами оценки в параметрах управления. Проверка завершается ошибкой, если этап не начал выполнение в течение указанного периода времени ожидания . Дополнительные сведения см. в разделе "Вызов задачи REST API ".

Примечание

Определяемые пользователем переменные конвейера не имеют доступа к проверке. Доступ к предопределенным переменным и переменным можно получить только из связанной группы переменных в тексте запроса.

Запрос оповещений Azure Monitor

Azure Monitor предлагает визуализацию, запрос, маршрутизацию, оповещение, автомасштабирование и автоматизацию данных из инфраструктуры Azure и каждого отдельного ресурса Azure. Оповещения — это стандартный способ обнаружения проблем с работоспособностью инфраструктуры или приложения и принятия корректирующих действий. Канарские развертывания и промежуточные развертывания — это распространенные стратегии развертывания, используемые для снижения риска регрессии к критически важным приложениям. После развертывания на этапе (набор клиентов) приложение наблюдается в течение определенного периода времени. Работоспособность приложения после развертывания используется для определения необходимости обновления на следующем этапе.

Запрос оповещений Azure Monitor помогает наблюдать за Azure Monitor и гарантировать отсутствие оповещений для приложения после развертывания. Проверка завершается успешно, если правила генерации оповещений не активируются во время оценки. Подробнее

Оценка повторяется после времени между параметрами оценки в параметрах управления. Проверка завершается ошибкой, если этап не начал выполнение в течение указанного периода времени ожидания .

Обязательный шаблон

При обязательной проверке шаблона можно применить конвейеры для использования определенного шаблона YAML. Если эта проверка выполняется, конвейер завершится ошибкой, если он не расширяется из указанного шаблона.

Чтобы определить обязательное утверждение шаблона, выполните следующие действия.

  1. В проекте Azure DevOps перейдите к подключению службы , которое вы хотите ограничить.

  2. Откройте утверждения и проверки в меню рядом с пунктом "Изменить".

  3. В меню "Добавить первую проверку " выберите "Обязательный шаблон".

  4. Введите сведения о том, как перейти к нужному файлу шаблона.

    • Тип репозитория: расположение репозитория (GitHub, Azure или Bitbucket).
    • Репозиторий: имя репозитория, содержащего шаблон.
    • Ссылка: ветвь или тег обязательного шаблона.
    • Путь к обязательному шаблону: имя шаблона.

Для одного подключения к службе можно использовать несколько обязательных шаблонов. В этом примере требуется required.ymlшаблон .

Настройка обязательной проверки шаблона.

Оценка артефакта

Вы можете оценить артефакты, которые будут развернуты в среде с помощью пользовательских политик.

Примечание

В настоящее время это работает только с артефактами образа контейнера

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

  1. В проекте Azure DevOps Services перейдите в среду, которую необходимо защитить. Узнайте больше о создании среды.

Просмотр среды.

  1. Перейдите к утверждениям и проверит среду.

Добавьте проверки в среду.

  1. Выберите "Оценить артефакт".

Добавьте проверку артефакта оценки.

  1. Вставьте определение политики и нажмите кнопку "Сохранить". Дополнительные сведения о написании определений политик.

Добавьте определение политики.

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

Просмотр пройденных проверок.

Вы также можете просмотреть полные журналы проверок политики в представлении конвейера.

Просмотр переданных журналов проверки.

Монопольная блокировка

Монопольная проверка блокировки позволяет продолжить только один запуск из конвейера. Все этапы всех запусков этого конвейера, которые используют ресурс, приостановлены. Когда этап, использующий блокировку, завершится, другой этап может перейти к использованию ресурса. Кроме того, будет разрешено продолжить только один этап.

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

  • runLatest — Только последний запуск получает блокировку для ресурса. runLatest — значение по умолчанию, если не lockBehavior указано.
  • sequential — Все запуски получают блокировку последовательно защищенному ресурсу.

Чтобы использовать монопольную проверку блокировки с sequential развертываниями или runLatestвыполните следующие действия.

  1. Включите монопольную проверку блокировки в среде (или другом защищенном ресурсе).
  2. В файле YAML для конвейера укажите свойство с именем lockBehavior. Это можно указать для всего конвейера или для определенного этапа:

Установка на этапе:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Задайте в конвейере:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Если не указать значение lockBehaviorпо умолчанию, используется значение runLatest по умолчанию.

Монопольная проверка блокировки позволяет продолжить только один запуск из конвейера. Все этапы всех запусков этого конвейера, которые используют ресурс, приостановлены. Когда этап, использующий блокировку, завершится, другой этап может перейти к использованию ресурса. Кроме того, будет разрешено продолжить только один этап. Все остальные этапы, которые пытались принять блокировку, будут отменены.

Управление изменениями ServiceNow

Для проверки необходимо установить расширение ServiceNow Change Management из Marketplace.

Проверка управления изменениями servicenow позволяет интегрировать процесс управления изменениями ServiceNow в конвейеры. Добавив проверку, новый запрос на изменение в ServiceNow можно автоматически создать в начале этапа. Конвейер ожидает завершения процесса изменения перед началом этапа. Дополнительные сведения можно найти здесь.

ВОПРОСЫ И ОТВЕТЫ

Определенные проверки не запускались. Что произошло?

Оценка проверок начинается после выполнения условий этапа. Вы должны подтвердить запуск этапа после добавления проверок в ресурс и что ресурс используется на этапе.

Как использовать проверки для планирования этапа?

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

Как принять предварительные утверждения для этапа, запланированного на запуск в будущем?

Этот сценарий можно включить

  1. Проверка рабочих часов позволяет запланировать выполнение всех этапов развертывания в ресурсе между временным периодом.
  2. Когда утверждения настроены на одном ресурсе, этап будет ожидать утверждений перед началом работы.
  3. Можно настроить обе проверки ресурса. Этап будет ждать утверждений и рабочих часов. Оно начнется в следующем запланированном окне после завершения утверждений.

Можно ли подождать завершения проверки безопасности развернутого артефакта?

Чтобы дождаться завершения проверки безопасности развернутого артефакта, необходимо использовать внешнюю службу сканирования, например AquaScan. Развертываемый артефакт должен быть отправлен в расположении, доступном службе сканирования перед началом проверок, и его можно определить с помощью предопределенных переменных. С помощью проверки REST API вызова можно добавить проверку, чтобы дождаться API в службе безопасности и передать идентификатор артефакта в качестве входных данных.

Как использовать выходные переменные из предыдущих этапов проверки?

По умолчанию для проверок доступны только предопределенные переменные. Для доступа к другим переменным можно использовать связанную группу переменных. Выходную переменную из предыдущего этапа можно записать в группу переменных и получить к ней доступ.