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

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

Несколько Утверждения и проверок

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

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

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

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

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

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

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

В этом выполнении:

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

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

1. Синхронный проверка с именем Sync Check 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 в службе безопасности и передать идентификатор артефакта в качестве входных данных.

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

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

Подробнее

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