Dodawanie etapów, zależności i warunków

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

Etap to granica logiczna w potoku usługi Azure DevOps. Etapy mogą służyć do grupowania akcji w procesie tworzenia oprogramowania (na przykład kompilowania aplikacji, uruchamiania testów, wdrażania w środowisku przedprodukcyjnym). Każdy etap zawiera co najmniej jedno zadania.

Podczas definiowania wielu etapów w potoku domyślnie są one uruchamiane po drugim. Etapy mogą również zależeć od siebie. Możesz użyć słowa kluczowego dependsOn , aby zdefiniować zależności. Etapy mogą być również uruchamiane na podstawie wyniku poprzedniego etapu z warunkami.

Aby dowiedzieć się, jak etapy współpracują z zadaniami równoległymi i licencjonowaniem, zobacz Konfigurowanie zadań równoległych i płacenie za nie.

Aby dowiedzieć się, jak etapy odnoszą się do innych części potoku, takich jak zadania, zobacz Kluczowe pojęcia dotyczące potoków.

Możesz również dowiedzieć się więcej o tym, jak etapy odnoszą się do części potoku w artykule dotyczącym etapów schematu YAML.

YAML

Zadania potoku można uporządkować w etapach. Etapy to główne podziały w potoku: kompilowanie tej aplikacji, uruchamianie tych testów i wdrażanie w środowisku przedprodukcyjnym to dobre przykłady etapów. Są to granice logiczne w potoku, w których można wstrzymać potok i wykonać różne kontrole.

Każdy potok ma co najmniej jeden etap, nawet jeśli nie zdefiniujesz go jawnie. Etapy można również rozmieścić w grafie zależności, tak aby jeden etap był uruchamiany przed innym. Istnieje limit 256 zadań dla etapu.

Klasyczny

Organizowanie zadań wdrażania w potoku wydania na etapy. Etapy to główne podziały w potoku wydania: uruchamianie testów funkcjonalnych, wdrażanie w środowisku przedprodukcyjnym i wdrażanie w środowisku produkcyjnym to dobre przykłady etapów wydania.

Etap w potoku wydania składa się z zadań i zadań.

Zatwierdzenia i bramy, warunki wdrożenia i wyzwalacze oraz kontrola zasad kolejkowania po wdrożeniu wydania na etapie.

Określanie etapów

YAML

W najprostszym przypadku nie potrzebujesz żadnych granic logicznych w potoku. W takim przypadku nie musisz jawnie używać słowa kluczowego stage . Zadania można określić bezpośrednio w pliku 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"

W przypadku organizowania potoku w wielu etapach użyj słowa kluczowego stages .

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

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

Jeśli zdecydujesz się określić wartość pool na poziomie etapu, wszystkie zadania zdefiniowane w tym etapie używają tej puli, chyba że określono je na poziomie zadania.

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

Pełna składnia określająca etap to:

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]

Klasyczny

Aby dodać etap do potoku wydania, wybierz potok wydania na stronie Wydania , wybierz akcję Edytuj , a następnie wybierz kartę Potok . Chociaż najważniejszą częścią definiowania etapu jest zadanie automatyzacji, można również skonfigurować kilka właściwości i opcji dla etapu w potoku wydania. Masz następujące możliwości:

• W razie potrzeby zmodyfikuj nazwę etapu.
• Wyznaczanie jednego użytkownika lub grupy jako właściciela etapu. Właściciele etapów otrzymują powiadomienia za każdym razem, gdy wdrożenie na tym etapie zakończy się niepowodzeniem. Bycie właścicielem etapu nie jest automatycznie dostarczane z żadnymi uprawnieniami.
• Usuń etap z potoku.
• Zmień kolejność etapów.
• Zapisz kopię etapu jako szablon etapu.
• Zarządzaj ustawieniami zabezpieczeń dla etapu.

Określanie zależności

YAML

Podczas definiowania wielu etapów w potoku domyślnie są one uruchamiane sekwencyjnie w kolejności, w której definiujesz je w pliku YAML. Wyjątkiem jest dodanie zależności. W przypadku zależności etapy są uruchamiane w kolejności dependsOn wymagań.

Potoki muszą zawierać co najmniej jeden etap bez zależności.

Składnia definiowania wielu etapów i ich zależności jest następująca:

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

Przykładowe etapy, które są uruchamiane sekwencyjnie:

# 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:
    ...

Przykładowe etapy, które są uruchamiane równolegle:

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:
    ...

Przykład wentylatora i wentylatora:

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

Klasyczny

Zależności można kontrolować, ustawiając wyzwalacze na każdym etapie potoku wydania:

• Etapy są uruchamiane przy użyciu wyzwalacza lub przez ręczne uruchomienie.
• W przypadku wyzwalacza Po wydaniu etap rozpoczyna się natychmiast po uruchomieniu wydania, równolegle z innymi etapami, które mają wyzwalacz Po wydaniu.
• Po wyzwoleniu etapu po zakończeniu wszystkich etapów zależnych etapy zostaną uruchomione. W tym celu można modelować zachowanie fan-out i fan-in dla etapów.

Definiowanie warunków

Możesz określić warunki, w których każdy etap jest uruchamiany z wyrażeniami. Domyślnie etap jest uruchamiany, jeśli nie zależy od innego etapu lub czy wszystkie etapy, od których zależy, zostały ukończone i zakończyły się pomyślnie. To zachowanie można dostosować, wymuszając uruchomienie etapu, nawet jeśli poprzedni etap zakończy się niepowodzeniem lub przez określenie warunku niestandardowego.

Jeśli dostosujesz domyślny warunek poprzednich kroków dla etapu, usuniesz warunki ukończenia i powodzenia. Dlatego jeśli używasz warunku niestandardowego, często należy and(succeeded(),custom_condition) sprawdzić, czy poprzedni etap został uruchomiony pomyślnie. W przeciwnym razie etap jest uruchamiany niezależnie od wyniku poprzedniego etapu.

Uwaga

Warunki niepowodzenia ('JOBNAME/STAGENAME') i powodzenia ('JOBNAME/STAGENAME'), jak pokazano w poniższym przykładzie działają tylko dla potoków YAML.

YAML

Przykład uruchamiania etapu na podstawie stanu uruchamiania poprzedniego etapu:

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')

Przykład użycia warunku niestandardowego:

stages:
- stage: A

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

Klasyczny

Po określeniu wyzwalaczy po wydaniu lub po etapie można również określić filtry gałęzi dla artefaktów używanych w wydaniu. Wydania będą wdrażane tylko na etapie, gdy filtry gałęzi są spełnione.

Określanie zasad kolejkowania

YAML

Potoki YAML nie obsługują zasad kolejkowania. Każde uruchomienie potoku jest niezależne od innych przebiegów. Innymi słowy, dwa kolejne zatwierdzenia mogą wyzwalać dwa potoki, a oba z nich będą wykonywać tę samą sekwencję etapów bez oczekiwania na siebie. Mimo że pracujemy nad wprowadzeniem zasad kolejkowania do potoków YAML, zalecamy użycie zatwierdzeń ręcznych w celu ręcznego sekwencjonowania i kontrolowania kolejności wykonywania, jeśli ma to znaczenie.

Klasyczny

W niektórych przypadkach możesz generować kompilacje szybciej niż można je wdrożyć. Alternatywnie można skonfigurować wielu agentów , a na przykład tworzyć wydania z tego samego potoku wydania na potrzeby wdrażania różnych artefaktów. W takich przypadkach warto kontrolować, jak wiele wydań jest umieszczanych w kolejce do etapu. Zasady kolejkowania zapewniają kontrolę.

Opcje, które można wybrać dla zasad kolejkowania, to:

• Liczba wdrożeń równoległych: użyj tej opcji, jeśli dynamicznie aprowizujesz nowe zasoby na etapie i fizycznie może obsługiwać wdrażanie wielu wydań równolegle, ale chcesz ograniczyć liczbę wdrożeń równoległych.

• Jeśli określisz maksymalną liczbę wdrożeń, pojawią się jeszcze dwie opcje:

  • Wdróż wszystko w sekwencji: użyj tej opcji, jeśli chcesz wdrożyć wszystkie wersje sekwencyjnie w tych samych udostępnionych zasobach fizycznych. Po wdrożeniu kompilacji po drugiej upewnij się, że dwa zadania wdrażania nie są przeznaczone dla tych samych zasobów fizycznych jednocześnie, nawet jeśli istnieje wiele dostępnych agentów kompilacji i wydania. Upewnij się również, że żądania zatwierdzenia przed wdrożeniem dla etapu są wysyłane w sekwencji.

  • Wdróż najnowsze i anuluj inne: użyj tej opcji, jeśli tworzysz kompilacje szybciej niż wydania i chcesz wdrożyć najnowszą kompilację.

Aby zrozumieć, jak działają te opcje, rozważ scenariusz, w którym wydania R1, R2, ..., R5 pojedynczego potoku wydania są tworzone w krótkim odstępie czasu. Załóżmy, że pierwszy etap w tym potoku nosi nazwę QA i ma zdefiniowane zarówno wstępne wdrożenie, jak i osoby zatwierdzające po wdrożeniu.

• Jeśli nie określisz limitu liczby wdrożeń równoległych, wszystkie pięć żądań zatwierdzenia zostanie wysłanych natychmiast po utworzeniu wersji. Jeśli osoby zatwierdzające zatwierdzają wszystkie wersje, zostaną one wdrożone równolegle na etapie kontroli jakości . (jeśli Etap kontroli jakości nie ma zdefiniowanych osób zatwierdzających przed wdrożeniem. Wszystkie pięć wersji zostanie automatycznie wdrożonych równolegle do tego etapu.

• Jeśli określisz limit i Wdróż wszystkie w sekwencji, a limit został już osiągnięty, zatwierdzenie przed wdrożeniem wersji R1 zostanie wysłane jako pierwsze. Po zakończeniu zatwierdzania rozpoczyna się wdrażanie wersji R1 na etapie kontroli jakości . Następnie zostanie wysłane żądanie zatwierdzenia po wdrożeniu dla wydania R1. Dopiero po zakończeniu zatwierdzania po wdrożeniu rozpoczyna się wykonywanie wersji R2 , a zatwierdzenie przed wdrożeniem jest wysyłane. Ten proces będzie kontynuowany dla wszystkich wersji z kolei.

• Jeśli określisz limit i wdróż najnowsze i anulujesz inne, a limit został już osiągnięty, wydania R2, R3 i R4 zostaną pominięte, a zatwierdzenie przed wdrożeniem dla języka R5 na etapie KONTROLI jakości zostanie wysłane natychmiast po zakończeniu zatwierdzania wersji R1 .

Określanie zatwierdzeń

YAML

Możesz ręcznie kontrolować, kiedy etap powinien być uruchamiany przy użyciu kontroli zatwierdzania. Jest to często używane do kontrolowania wdrożeń w środowiskach produkcyjnych. Kontrole są mechanizmem dostępnym dla właściciela zasobu w celu kontrolowania, czy i kiedy etap w potoku może zużywać zasób. Jako właściciel zasobu, takiego jak środowisko, można zdefiniować kontrole, które muszą być spełnione przed rozpoczęciem etapu zużywania tego zasobu.

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

Klasyczny

Zatwierdzenia ręczne można dodawać na początku lub na końcu każdego etapu w potoku. Aby uzyskać więcej informacji, zobacz Omówienie zatwierdzeń wersji i bram.