stages.stage definition

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 właściwości 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.

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.
  templateContext: # Stage related information passed from a pipeline when extending a template.

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

stage ciąg. Wymagane jako pierwsza właściwość.
identyfikator etapu.

displayName ciąg.
czytelna dla człowieka nazwa etapu.

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

ciąg dependsOn | 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: [] dla etapu, 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.

variables zmiennych.
zmiennych specyficznych dla etapu.

jobs zadania.
Zadania, które tworzą etap.

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

trigger ciąg.
wyzwalacz etapu ręczny lub automatyczny (ustawienie domyślne). ręczne | Automatyczne.

isSkippable wartość logiczna.
ustawienie false uniemożliwia pomijanie etapu. Domyślnie jest to zawsze prawdziwe.

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

Aby uzyskać więcej informacji na temat templateContext, zobacz szablony rozszerzonych potoków YAML można teraz przekazywać informacje kontekstowe dla etapów, zadań i wdrożeń i szablonów — użyj szablonuContext, aby przekazać właściwości do szablonów.

Blokada wyłączna

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

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

• runLatest — tylko najnowszy przebieg uzyskuje blokadę zasobu. Jest to wartość domyślna, jeśli nie określono lockBehavior.
• sequential — wszystkie uruchomienia 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 właściwość lockBehavior, 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łącznej kontroli blokady w przypadku wdrożeń sequential lub runLatest, wykonaj następujące kroki:

1. Włącz wyłączne sprawdzanie blokady 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 etapie:

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!

Blokada na wyłączność na poziomie etapu

Niektóre przypadki użycia wymagają potoku, aby uzyskać dostęp do określonego zasobu tylko raz w danym momencie. W tym przypadku mamy wyłączną kontrolę blokady opisaną w poprzedniej sekcji.

Podobna sytuacja występuje, gdy tylko jedno uruchomienie potoku powinno uzyskać dostęp do etapu w dowolnym momencie. Jeśli na przykład masz etap, który jest wdrażany w grupie zasobów platformy Azure, możesz uniemożliwić jednoczesne aktualizowanie tej samej grupy zasobów przez wiele przebiegów potoku. Obecnie osiągnięcie tego celu wymaga użycia zasobu serwera proxy, takiego jak środowisko, i umieszczenie wyłącznego sprawdzania blokady w tym środowisku. Takie podejście może być czasochłonne, zwiększać złożoność i zwiększać nakłady pracy konserwacyjne.

Jeśli musisz mieć pewność, że tylko jedno uruchomienie potoku w danym momencie będzie mieć dostęp do etapu, możesz określić wyłączną blokadę na poziomie etapu. Jeśli masz etap z identyfikatorem i określisz jego właściwość lockBehavior, dla tego etapu zostanie automatycznie utworzona blokada. Zachowanie sekwencyjne pozostaje spójne zarówno dla blokad na poziomie zasobów, jak i na poziomie etapu. Jednak zachowanie runLatest różni się, ponieważ anuluje tylko runLatest kompilacje dla tej samej gałęzi, a nie dla wszystkich gałęzi potoku.