определение stage.stage

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

stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.
  lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  trigger: manual | automatic # Stage trigger manual or automatic (default).
  isSkippable: boolean # Setting false prevents the stage from being skipped. By default it's always true.
  templateContext: # Stage related information passed from a pipeline when extending a template.

Определения, ссылающиеся на это определение: этапы

Свойства

строка stage. Обязательный в качестве первого свойства.
идентификатор этапа.

строка displayName.
имя, доступное для чтения человеком для этапа.

pool пула.
пул, где задания на этом этапе будут выполняться, если иное не указано.

строка dependsOn | строковый список.
Любые этапы, которые должны завершиться до этого. По умолчанию этапы выполняются последовательно в порядке, определенном в конвейере. Укажите dependsOn: [] для этапа, если он не должен зависеть от предыдущего этапа конвейера.

строка condition.
оценить это выражение условия, чтобы определить, следует ли выполнять этот этап.

variables переменных.
переменные, относящиеся к этапу.

jobs задания.
задания, составляющие этап.

строка lockBehavior.
запросы на блокировку поведения на этом этапе должны быть представлены в отношении других эксклюзивных запросов блокировки. последовательный | runLatest.

строка trigger.
триггер этапа вручную или автоматически (по умолчанию). вручную | Автоматически.

isSkippable логические.
параметр false предотвращает пропуск этапа. По умолчанию это всегда верно.

templateContext templateContext.
сведения, связанные с этапом, передаваемые из конвейера при расширении шаблона. Дополнительные сведения о templateContextсм. в статье Расширенные шаблоны конвейеров YAML теперь можно передавать сведения о контексте для этапов, заданий и развертываний и шаблонов. Используйте templateContext для передачи свойств в шаблоны.

Замечания

Дополнительные сведения о templateContextсм. в статье Расширенные шаблоны конвейеров YAML теперь можно передавать сведения о контексте для этапов, заданий и развертываний и шаблонов. Используйте templateContext для передачи свойств в шаблоны.

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

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

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

Монопольная блокировка

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

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

• runLatest. Только последний запуск получает блокировку ресурса. Это значение по умолчанию, если не указано lockBehavior.
• sequential. Все запуски получают блокировку последовательно к защищенному ресурсу.

Отмена старых запусков является хорошим подходом, когда выпуски являются накопительными и содержат все изменения кода из предыдущих запусков. Однако существуют некоторые конвейеры, в которых изменения кода не являются накопительными. Настроив свойство lockBehavior, можно разрешить все запуски продолжать и развертывать последовательно в среде или сохранять предыдущее поведение отмены старых запусков и разрешить только последнюю версию. Значение sequential подразумевает, что все запуски получают блокировку последовательно для защищенного ресурса. Значение runLatest означает, что только последний запуск получает блокировку для ресурса.

Чтобы использовать монопольную проверку блокировки с развертываниями 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!

Монопольная блокировка на уровне стадии

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

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

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

Примеры

В этом примере последовательно выполняются три этапа. Средний этап выполняет два задания параллельно.

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building!
- stage: Test
  jobs:
  - job: TestOnWindows
    steps:
    - script: echo Testing on Windows!
  - job: TestOnLinux
    steps:
    - script: echo Testing on Linux!
- stage: Deploy
  jobs:
  - job: Deploy
    steps:
    - script: echo Deploying the code!

В этом примере выполняется два этапа параллельно. Для краткости задания и шаги опущены.

stages:
- stage: BuildWin
  displayName: Build for Windows
- stage: BuildMac
  displayName: Build for Mac
  dependsOn: [] # by specifying an empty array, this stage doesn't depend on the stage before it

См. также

Дополнительные сведения о этапах , условиях и переменных.