stages.stage definition

  • Artykuł

Etapy to kolekcja powiązanych zadań. Domyślnie etapy są uruchamiane sekwencyjnie. Każdy etap rozpoczyna się dopiero po zakończeniu poprzedniego etapu, chyba że określono inaczej za pośrednictwem dependsOn właściwości .

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: string # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  templateContext: # Stage related information passed from a pipeline when extending a template.

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.

Definicje odwołujące się do tej definicji: etapy

Właściwości

stage Ciąg. Wymagane jako pierwsza właściwość.
Identyfikator etapu.

displayName Ciąg.
Czytelna dla człowieka nazwa etapu.

poolpula.
Pula, w której zadania na tym etapie będą uruchamiane, chyba że określono inaczej.

dependsOn ciąg | lista ciągów.
Wszystkie etapy, które muszą zostać ukończone przed tym etapem. Domyślnie etapy są uruchamiane sekwencyjnie w kolejności zdefiniowanej w potoku. Określ dependsOn: [] etap, jeśli nie powinien zależeć od poprzedniego etapu w potoku.

condition Ciąg.
Oceń to wyrażenie warunku, aby określić, czy należy uruchomić ten etap.

variableszmienne.
Zmienne specyficzne dla etapu.

jobszadania.
Zadania, które tworzą etap.

lockBehavior Ciąg.
Żądania blokady zachowania z tego etapu powinny być wystawiane w odniesieniu do innych żądań blokady wyłącznej. sekwencyjny | runLatest.

templateContext templateContext.
Informacje dotyczące etapu przekazywane z potoku podczas rozszerzania szablonu. Aby uzyskać więcej informacji na temat templateContextprogramu , zobacz Rozszerzone szablony potoków YAML można teraz przekazywać informacje kontekstowe dla etapów, zadań i wdrożeń oraz szablonów— użyj szablonuContext, aby przekazać właściwości do szablonów.

Uwagi

Użyj kontroli zatwierdzenia , aby ręcznie kontrolować, kiedy należy uruchomić etap. Te kontrole są często używane do kontrolowania wdrożeń w środowiskach produkcyjnych.

Kontrole są mechanizmem dostępnym dla właściciela zasobu. Określają, kiedy etap w potoku zużywa zasób. Jako właściciel zasobu, takiego jak środowisko, możesz zdefiniować kontrole wymagane przed rozpoczęciem etapu, który zużywa zasób.

Obecnie testy zatwierdzania ręcznego są obsługiwane w środowiskach. Aby uzyskać więcej informacji, zobacz Zatwierdzenia.

Blokada wyłączna

W potokach YAML kontrole służą do kontrolowania wykonywania etapów w chronionych zasobach. Jedną z typowych kontroli, których można użyć, jest wyłączna kontrola blokady. To sprawdzenie umożliwia kontynuowanie tylko jednego uruchomienia z potoku. Gdy wiele przebiegów próbuje wdrożyć w środowisku w tym samym czasie, kontrola anuluje wszystkie stare przebiegi i zezwala na wdrożenie najnowszego uruchomienia.

Zachowanie sprawdzania blokady wyłącznej można skonfigurować przy użyciu lockBehavior właściwości , która ma dwie wartości:

  • runLatest — Tylko najnowszy przebieg uzyskuje blokadę zasobu. Jest to wartość domyślna, jeśli nie lockBehavior jest określona.
  • sequential - Wszystkie przebiegi uzyskują blokadę sekwencyjnie do chronionego zasobu.

Anulowanie starych przebiegów jest dobrym rozwiązaniem, gdy wydania są zbiorcze i zawierają wszystkie zmiany kodu z poprzednich przebiegów. Istnieją jednak potoki, w których zmiany kodu nie są skumulowane. Konfigurując lockBehavior właściwość, można zezwolić wszystkim przebiegom na kontynuowanie i wdrażanie sekwencyjnie w środowisku lub zachować poprzednie zachowanie anulowania starych przebiegów i zezwalania tylko na najnowsze. Wartość sequential oznacza, że wszystkie uruchomienia uzyskują blokadę sekwencyjnie do chronionego zasobu. Wartość runLatest oznacza, że tylko najnowszy przebieg uzyskuje blokadę zasobu.

Aby użyć wyłącznego sprawdzania blokady sequential we wdrożeniach lub runLatest, wykonaj następujące kroki:

  1. Włącz kontrolę wyłącznych blokad w środowisku (lub inny chroniony zasób).
  2. W pliku YAML potoku określ nową właściwość o nazwie lockBehavior. Można to określić dla całego potoku lub dla danego etapu:

Ustaw na scenie:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ustaw w potoku:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Przykłady

W tym przykładzie są uruchamiane trzy etapy— jeden po drugim. Środkowy etap uruchamia dwa zadania równolegle.

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!

W tym przykładzie są uruchamiane dwa etapy równolegle. W celu zwięzłości pominięto zadania i kroki.

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

Zobacz też

Dowiedz się więcej o etapach, warunkach i zmiennych.