Добавление этапов, зависимостей и условий

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Сведения о том, как этапы работают с параллельными заданиями и лицензированием, см. в статье "Настройка и оплата параллельных заданий".

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

Дополнительные сведения о том, как этапы связаны с частями конвейера в статье о стадиях схемы YAML.

YAML

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

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

Классическое

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

Этап в конвейере выпуска состоит из заданий и задач.

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

Указание этапов

YAML

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

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

При организации конвейера на нескольких этапах используется ключевое stages слово.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Если вы решили указать на pool уровне этапа, то все задания, определенные на этом этапе, используют этот пул, если не указано на уровне задания.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

Полный синтаксис для указания этапа:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Классическое

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

• При необходимости измените имя этапа.
• Назначьте одного пользователя или группы владельцем этапа. Владельцы этапов получают уведомления всякий раз, когда развертывание на этом этапе завершается сбоем. Будучи владельцем стадии, автоматически не предоставляется никаких разрешений.
• Удалите этап из конвейера.
• Изменение порядка этапов.
• Сохраните копию этапа в виде шаблона этапа.
• Управление параметрами безопасности для этапа.

Указание зависимостей

YAML

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

Конвейеры должны содержать по крайней мере один этап без зависимостей.

Синтаксис определения нескольких этапов и их зависимостей:

stages:
- stage: string
  dependsOn: string
  condition: string

Примеры этапов, которые выполняются последовательно:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Примеры этапов, которые выполняются параллельно:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Пример вентилятора и вентилятора:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Классическое

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

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

Определение условий

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

Если вы настраиваете условие по умолчанию предыдущих шагов для этапа, удалите условия завершения и успешности. Таким образом, если вы используете настраиваемое условие, обычно используется and(succeeded(),custom_condition) для проверки успешности выполнения предыдущего этапа. В противном случае этап выполняется независимо от результата предыдущего этапа.

Примечание.

Условия сбоя ('JOBNAME/STAGENAME') и успешно завершены ('JOBNAME/STAGENAME'), как показано в следующем примере, работают только для конвейеров YAML.

YAML

Пример запуска этапа на основе состояния выполнения предыдущего этапа:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Пример использования настраиваемого условия:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Классическое

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

Указание политик очередей

YAML

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

Классическое

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

Варианты, которые можно выбрать для политики очередей:

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

• Если указать максимальное количество развертываний, появится еще два варианта:

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

  • Разверните последние и отмените другие. Используйте этот параметр, если вы создаете сборки быстрее, чем выпуски, и вы хотите развернуть последнюю сборку.

Чтобы понять, как работают эти параметры, рассмотрим сценарий, в котором выпуски R1, R2, ..., R5 одного конвейера выпуска создаются в быстром последовательности. Предположим, что первый этап в этом конвейере называется QA и имеет предварительное и после развертывания утверждающие.

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

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

• Если указать ограничение и развернуть последнюю и отменить остальные, и ограничение уже достигнуто, выпуски R2, R3 и R4 будут пропущены, а утверждение предварительного развертывания для R5 на этапе качества обслуживания будет отправлено сразу после завершения утверждения выпуска R1 .

Указание утверждений

YAML

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

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

Классическое

Можно добавить утверждения вручную в начале или конце каждого этапа в конвейере. Дополнительные сведения см. в разделе "Утверждения выпуска" и "Шлюзы".

Добавление триггера вручную

Этапы конвейера YAML вручную позволяют иметь единый конвейер, не выполняя его до завершения.

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

Чтобы использовать эту функцию, добавьте trigger: manual свойство на сцену.

В следующем примере этап разработки выполняется автоматически, а этап рабочей среды требует активации вручную. Оба этапа запускают скрипт вывода hello world.

stages:
- stage: development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Пометить сцену как неуправляемую

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

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

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

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