Поделиться через

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

  • Статья

Azure DevOps Services

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

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

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

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

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

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

Статические проверки выполняются сначала, а затем выполняются предварительные проверки утверждений. Категории перечислены в порядке:

  1. Статические проверки: управление ветвью, требуемый шаблон и оценка артефакта
  2. Предварительные проверки утверждений
  3. Динамические проверки: утверждение, вызов функции Azure, вызов REST API, рабочие часы, запрос оповещений Azure Monitor
  4. Утверждения после проверки
  5. Монопольная блокировка

Вы также можете просмотреть порядок выполнения на вкладке "Утверждения и проверки ".

Внимание

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

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

Утверждения

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

  1. Войдите в организацию Azure DevOps и перейдите к проекту.

  2. Выберите Конвейеры>Среды и выберите свою среду.

  3. Выберите вкладку "Утверждения и проверки ", а затем выберите + знак, чтобы добавить новую проверку.

    Снимок экрана: добавление утверждений и проверок в Azure Pipelines.

  4. Выберите "Утверждения" и нажмите кнопку "Далее".

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

  6. После завершения работы выберите Создать.

    Снимок экрана, показывающий, как создать новое одобрение.

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

    Снимок экрана: окно запроса утверждения.

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

Примечание.

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

Отложенные согласования

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

Чтобы устранить этот сценарий, можно отложить утверждение и задать время, когда утверждение станет эффективным.

  1. Выберите "Отложить утверждение".

    Снимок экрана: вариант отложить утверждение при ответе на запрос на утверждение.

  2. Задайте время утверждения.

    Снимок экрана: задание времени утверждения.

Вы увидите одобрение на панели "Проверки" как предварительное одобрение. Утверждение действует в заданное время.

Управление ветвями

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

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

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

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

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

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

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

Примечание.

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

Рабочие часы

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

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

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

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

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

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

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

Примечание.

Определяемые пользователем переменные конвейера доступны для проверки, начиная с Sprint 215.

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

Вызов REST API

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

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

Примечание.

Определяемые пользователем переменные конвейера доступны для проверки, начиная с Sprint 215.

Узнайте больше о рекомендуемом способе вызова проверок REST API.

Запросить оповещения Azure Monitor

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

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

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

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

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

Чтобы определить требуемое утверждение шаблона, выполните следующее:

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

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

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

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

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

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

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

Отключение проверки

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

  1. В проекте Azure DevOps перейдите к ресурсу с галочкой.

  2. Откройте вкладку "Утверждения и проверки ".

  3. В контекстном меню выберите "Отключить " или "Включить".

    Снимок экрана: отключение параметра проверки.

Обход проверки

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

Чтобы пропустить шаги утверждения, рабочие часы, запуск функции Azure или проверку REST API, выберите "Обход проверки", когда ресурс ожидает утверждения. Ниже приведен пример обхода проверки рабочих часов.

Снимок экрана опции обхода проверки рабочих часов.

При обходе проверки вы увидите, кто обошел проверку на панели проверок.

Снимок экрана журнала пропущенной проверки.

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

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

Примечание.

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

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

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

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

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

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

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

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

  4. Вставьте определение политики и нажмите кнопку "Сохранить". Узнайте больше о написании определений политик.

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

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

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

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

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

Исключительная блокировка

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

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

  • 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 можно автоматически создать в начале этапа. Конвейер ожидает завершения процесса изменения перед началом этапа. Дополнительные сведения можно найти здесь.

Несколько согласований и проверок

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

Одно окончательное отрицательное решение приводит к отказу в доступе к конвейеру, и стадия завершается ошибкой. Решения всех утверждений и проверок, кроме вызова функции Azure или REST API и монопольной блокировки, являются окончательными. Вы можете повторно запустить успешный вызов функции Azure или проверки REST API.

При использовании проверки через вызов функции Azure или REST API рекомендованным способом их решения об доступе также являются окончательными.

При указании времени между оценками для выполнения функции Azure или проверки REST API в ненулевое значение, решение проверки не является окончательным. Этот сценарий стоит изучить.

Рассмотрим пример. Представьте, что ваш конвейер YAML содержит стадию, использующую сервис-соединение. Это подключение службы настроено на две проверки.

  1. Асинхронная проверка с именем "Внешнее утверждение предоставлено", которая проверяет, предоставлено ли внешнее утверждение и настроено рекомендуемым образом.
  2. Синхронная проверка с именем "Причина развертывания допустима", которая проверяет, является ли причина развертывания допустимой и для которой устанавливается время между оценками до 7 минут.

Возможное выполнение проверок показано на следующей схеме. Схема, показывающая временную шкалу асинхронных и синхронных проверок.

В этом исполнении:

  • Одновременно вызываются обе проверки: внешнее утверждение предоставлено и причина развертывания действительна. Причина развертывания недействительна завершается сбоем немедленно, но так как внешнее утверждение ожидается, он повторяется.
  • На 7-й минуте проверка допустимости причины развертывания повторяется, и на этот раз она успешно проходит.
  • На 15-й минуте предоставлено внешнее утверждение, что вызвало обратный вызов в Azure Pipelines с успешным решением. Теперь оба проверки проходят, поэтому конвейер может продолжить развертывание этапа.

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

  1. Синхронная проверка с именем Синхронная проверка 1, для которой задается время между оценками до 5 минут.
  2. Синхронная проверка с именем Sync Check 2, для которой задано время между оценками 7 минут.

Возможное выполнение проверок показано на следующей схеме. Схема, на которую показана временная шкала двух синхронных проверок.

В этой реализации:

  • Обе проверки, проверка синхронизации 1 и проверка синхронизации 2, вызываются одновременно. Проверка синхронизации 1 проходит, но она выполняется повторно, так как проверка синхронизации 2 завершается ошибкой.
  • В минуту 5 проверка синхронизации 1 выполняется повторно, но завершается ошибкой, поэтому она выполняется повторно.
  • В минуту 7 проверка синхронизации 2 выполняется повторно и успешно выполнена. Решение действительно на 7 минут. Если проверка синхронизации 1 не проходит в этом интервале времени, выполняется повторная проверка синхронизации 2 .
  • На 10-й минуте проверка синхронизации 1 повторена, но снова завершается ошибкой, поэтому повторяется.
  • В минуту 14 проверка синхронизации 2 выполняется повторно и успешно выполнена. Принятое решение действительно в течение 7 минут. Если проверка синхронизации 1 не проходит в этом интервале времени, выполняется повторная проверка синхронизации 2 .
  • В минуту 15 проверка синхронизации 1 выполняется повторно и успешно выполняется. Теперь оба проверки проходят, поэтому конвейер может продолжить развертывание этапа.

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

Вопросы и ответы

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

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

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

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

Как получить предварительные одобрения для стадии, запланированной на будущее?

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

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

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

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

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

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

Подробнее