Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Этап — это логическая граница в конвейере Azure DevOps. Этапы группирования действий в процессе разработки программного обеспечения, такие как создание приложения, выполнение тестов и развертывание в предварительной версии. Каждый этап содержит одно или несколько заданий.
При определении нескольких этапов конвейера по умолчанию они выполняются один после другого. Этапы также могут зависеть друг от друга. Ключевое dependsOn
слово можно использовать для определения зависимостей. Этапы также могут выполняться на основе результата предыдущего этапа при наличии условий.
Сведения о том, как этапы работают с параллельными заданиями и лицензированием, см. в статье "Настройка и оплата параллельных заданий".
Чтобы узнать, как этапы связаны с другими частями потока данных, например, работами, см. Основные понятия потока данных.
Дополнительные сведения о взаимосвязи этапов и частей конвейера можно найти в статье о стадиях в схеме YAML.
Задания конвейера можно упорядочить по этапам. Этапы являются основными подразделениями в конвейере: создание этого приложения, выполнение этих тестов и развертывание в предварительной версии являются хорошими примерами этапов. Они логические границы в конвейере, где можно приостановить конвейер и выполнить различные проверки.
Каждый конвейер имеет по крайней мере один этап, даже если он не определен явным образом. Вы также можете упорядочить этапы в графе зависимостей так, чтобы один этап выполнялся перед другим. Этап может содержать до 256 заданий.
Указание этапов
В самом простом случае в конвейере не требуются логические границы. В этих сценариях можно напрямую указать задания в файле YAML без ключевого stages
слова. Например, если у вас есть простой конвейер, который создает и тестирует небольшое приложение, не требуя отдельных сред или шагов развертывания, можно определить все задания непосредственно без использования этапов.
pool:
vmImage: 'ubuntu-latest'
jobs:
- job: BuildAndTest
steps:
- script: echo "Building the application"
- script: echo "Running tests"
Этот конвейер включает одну неявную стадию и две задачи. Ключевое stages
слово не используется, так как существует только один этап.
jobs:
- job: Build
steps:
- bash: echo "Building"
- job: Test
steps:
- bash: echo "Testing"
Чтобы упорядочить конвейер на нескольких этапах, используйте ключевое stages
слово. Этот YAML определяет конвейер с двумя этапами, в которых каждый этап содержит несколько заданий, и каждое задание имеет определенные шаги для выполнения.
stages:
- stage: A
displayName: "Stage A - Build and Test"
jobs:
- job: A1
displayName: "Job A1 - build"
steps:
- script: echo "Building the application in Job A1"
displayName: "Build step"
- job: A2
displayName: "Job A2 - Test"
steps:
- script: echo "Running tests in Job A2"
displayName: "Test step"
- stage: B
displayName: "Stage B - Deploy"
jobs:
- job: B1
displayName: "Job B1 - Deploy to Staging"
steps:
- script: echo "Deploying to staging in Job B1"
displayName: "Staging deployment step"
- job: B2
displayName: "Job B2 - Deploy to Production"
steps:
- script: echo "Deploying to production in Job B2"
displayName: "Production deployment step"
Если вы задаете 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
Указание зависимостей
При определении нескольких этапов конвейера они выполняются последовательно по умолчанию в порядке их определения в файле YAML. Исключением из этого является добавление зависимостей. При использовании зависимостей этапы выполняются в порядке dependsOn
требований.
Конвейеры должны содержать по крайней мере один этап без зависимостей.
Дополнительные сведения о том, как определить этапы, см. этапы в схеме YAML.
В следующем примере этапы выполняются последовательно. Если ключевое dependsOn
слово не используется, этапы выполняются в определенном порядке.
stages:
- stage: Build
displayName: "Build Stage"
jobs:
- job: BuildJob
steps:
- script: echo "Building the application"
displayName: "Build Step"
- stage: Test
displayName: "Test Stage"
jobs:
- job: TestJob
steps:
- script: echo "Running tests"
displayName: "Test Step"
Примеры этапов, которые выполняются параллельно:
stages:
- stage: FunctionalTest
displayName: "Functional Test Stage"
jobs:
- job: FunctionalTestJob
steps:
- script: echo "Running functional tests"
displayName: "Run Functional Tests"
- stage: AcceptanceTest
displayName: "Acceptance Test Stage"
dependsOn: [] # Runs in parallel with FunctionalTest
jobs:
- job: AcceptanceTestJob
steps:
- script: echo "Running acceptance tests"
displayName: "Run Acceptance Tests"
Пример поведения схемы разветвления (fan-out) и объединения (fan-in):
stages:
- stage: Test
- stage: DeployUS1
dependsOn: Test # stage runs after Test
- stage: DeployUS2
dependsOn: Test # stage runs in parallel with DeployUS1, after Test
- stage: DeployEurope
dependsOn: # stage runs after DeployUS1 and DeployUS2
- DeployUS1
- DeployUS2
Определение условий
Вы можете указать условия, при которых выполняется каждый этап, через выражения. По умолчанию этап выполняется, если он не зависит от какого-либо другого этапа, или если все этапы, от которых он зависит, завершены и успешны. Это поведение можно настроить путем принудительного запуска этапа, даже если предыдущий этап завершается сбоем или путем указания настраиваемого условия.
Если вы настраиваете условия по умолчанию предыдущих шагов для стадии, вы удаляете условия завершения и успеха. Таким образом, если вы используете настраиваемое условие, обычно используется and(succeeded(),custom_condition)
для проверки успешности выполнения предыдущего этапа. В противном случае этап выполняется независимо от результата предыдущего этапа.
Примечание.
Условия для проваленных ('JOBNAME/STAGENAME') и успешных ('JOBNAME/STAGENAME'), как показано в следующем примере, работают только для 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 конвейере позволяют иметь единый конвейер без необходимости полного выполнения.
Например, конвейер может включать этапы создания, тестирования, развертывания в промежуточной среде и развертывания в рабочей среде. Может потребоваться, чтобы все этапы запускались автоматически, за исключением рабочего развертывания, которое вы предпочитаете активировать вручную при готовности.
Чтобы использовать эту функцию, добавьте trigger: manual
свойство на этап.
В следующем примере этап разработки выполняется автоматически, а этап рабочей среды требует активации вручную. Оба этапа запускают скрипт, выводящий "привет, мир".
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
...
Если этап нельзя пропустить, он отображается с выключенным флажком в панели Этапы для запуска конфигурации.