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

Azure DevOps Services

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

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

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

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

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

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

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

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

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

Внимание

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

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

Утверждения

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

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

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

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

   

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

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

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

   

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

   

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

Примечание.

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

Отложенные утверждения

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

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

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

   

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

   

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

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

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

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

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

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

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

   

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

Примечание.

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

Рабочие часы

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

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

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

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

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

Примечание.

Определяемые пользователем переменные конвейера доступны для проверки, начиная с 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 invoke можно добавить проверку, чтобы ждать API в службе безопасности и передать идентификатор артефакта в качестве входных данных.

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

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

Подробнее

• Вызов проверки функции Azure или REST API
• Утверждения и проверки REST API
• REST API запросов утверждений