Budowanie potoku YAML z etapami

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Dzięki wielu etapom można odizolować różne części procesu, poprawić kontrolę jakości i bezpieczeństwo, uzyskać lepszy wgląd w postęp procesu oraz ograniczyć ryzyko.

W tym artykule dowiesz się, jak utworzyć i uruchomić bardziej złożony pipeline YAML z wieloma etapami i warunkami. Przykładowa kolejka obejmuje etapy kompilacji, testowania i wdrażania, a także opcjonalne etapy dla wdrożeń alternatywnych i wycofywania. Etap wycofywania umożliwia szybkie przywrócenie stabilnej wersji, jeśli coś pójdzie nie tak, zwiększając niezawodność i stabilność.

Ten kod działa w większości scenariuszy, ale nie obejmuje wymagań specyficznych dla języka ani platformy. W następnym kroku dostosuj potok do konkretnych potrzeb implementacji.

Aby dowiedzieć się, jak utworzyć klasyczny pipeline z fazami, zobacz Wdrażanie do różnych faz z wielu gałęzi przy użyciu klasycznych pipeline'ów wydania.

Warunki wstępne

produkt Wymagania
Azure DevOps — projekt usługi Azure DevOps.
— Możliwość uruchamiania pipeline'ów na agentach hostowanych przez firmę Microsoft. Możesz albo kupić zadanie równoległe , albo poprosić o bezpłatny poziom.
— Podstawowa wiedza na temat języka YAML i usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Utwórz swój pierwszy potok.
Uprawnienia: -
     Aby utworzyć potok, użytkownicy muszą znajdować się w grupie Kontrybutorzy, a grupa musi mieć uprawnienie Budowanie potoku ustawione na wartość Zezwalaj. Członkowie grup Administratorzy Kompilacji i Administratorzy Projektu mogą również zarządzać potokami.
GitHub — Konto GitHub .
Połączenie usługi GitHub do autoryzowania usługi Azure Pipelines.
Błękit Subskrypcja platformy Azure.

1. Stwórz początkowy przepływ

  1. W projekcie usługi Azure DevOps wybierz opcję Potoki>Utwórz potok, a następnie wybierz GitHub jako lokalizację kodu źródłowego.
  2. Na ekranie Wybór repozytorium wybierz swoje repozytorium.
  3. Na ekranie Konfigurowanie potoku , wybierz potok startowy.
  4. Zapisz potok.

2. Dodawanie etapu kompilacji

Potok początkowy dodany w poprzednim etapie był symbolem zastępczym. Usuń kod początkowego rurociągu i dodaj nowy rurociąg YAML z etapem kompilacji.

  1. Usuń cały kod w linii przetwarzania.

  2. Zastąp kod następującym kodem YAML zawierającym etap Build.

    trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build Stage'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: |
        echo "Restoring project dependencies..."
      displayName: 'Restore dependencies'
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

W tym etapie Build i w całym potoku danych znajdują się zadania skryptów zastępczych. Podczas tworzenia potoku roboczego zastąp zastępcze polecenia, takie jak Restoring project dependencies... rzeczywistym kodem.

W tym przykładzie przywracasz zależności i uruchamiasz testy jednostkowe, aby upewnić się, że kod jest gotowy do testowania i wdrażania. Jeśli aplikacja musi skompilować kod źródłowy, nastąpi to również na etapie Build.

3. Dodawanie etapu testu

Etap Test uruchamia testy w projekcie i publikuje wyniki testów w usłudze Azure DevOps. Aby dowiedzieć się więcej na temat publikowania wyników testu, zobacz zadanie publikowanie wyników testu .

Etap Test jest uruchamiany tylko wtedy, gdy etap Build zakończy się pomyślnie i nie można pominąć etapu.

Dodaj etap Test po etapie Build w potoku.

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

Etap testowy zawiera atrybut, który ustawia isSkippable na false. Po ustawieniu isSkippable na falsenie można pominąć etapu. Opcja pominięcia etapu jest również wyłączona w interfejsie użytkownika usługi Azure DevOps.

Zrzut ekranu przedstawiający etap, którego nie można pominąć.

4. Wdrażanie w środowisku testowym

Dodaj etap DeployToStaging po etapie Test w potoku.

Etap DeployToStaging zależy od etapu Test, aby się uruchomić. Na etapie DeployToStaging istnieją dwa różne zadania — DeployStagingJob i DeployStagingJobWithValidation. DeployStagingJob powinien zawierać kod umożliwiający wdrożenie zadania przejściowego w zasobach przejściowych, takich jak serwer przejściowy.

Zadanie DeployStagingJobWithValidation zawiera całą walidację, która jest częścią wdrożenia przejściowego. Zadanie DeployStagingJobWithValidation wymaga ręcznego zatwierdzenia. Zadanie ręcznej weryfikacji wstrzymuje przebieg potoku i czeka na interakcję ręczną. Użytkownik musi zweryfikować etap przed kontynuowaniem przebiegu. Posiadanie ręcznego zatwierdzania w procesie dodaje kolejny poziom zabezpieczeń, pomaga ograniczyć ryzyko i zapewnić, że wszystkie zmiany są weryfikowane przez odpowiednich interesariuszy.

Pula ręcznego zatwierdzania jest server. Ręczne walidacje są wykonywane wyłącznie w ramach puli serwerów.

- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

5. Wdrażanie w środowisku produkcyjnym

Dodaj etap DeployToProduction po etapie DeployToStaging w potoku.

Na etapie DeployToProduction aplikacja jest wdrażana w środowisku produkcyjnym, ale tylko wtedy, gdy etap DeployToStaging zakończy się powodzeniem, a gałąź źródłowa jest main lub release.

Na etapie DeployToProduction istnieją dwa różne zadania — DeployProductionJob i waitForValidation.

Zadanie ręcznej weryfikacji w waitForValidation dodaje drugi krok weryfikacji przez człowieka na potrzeby zabezpieczeń i kontroli jakości. Na etapie DeployToStaging użyliśmy również zadania ręcznego sprawdzania poprawności.

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

6. Dodawanie opcjonalnych alternatywnych etapów produkcji i wycofywania

Opcjonalnie można dodać dwa etapy DeployToAlternateProduction i Rollback po etapie DeployToProduction.

DeployToAlternateProduction i Rollback są ręcznie kolejkowane. Etap DeployToAlternateProduction umożliwia przygotowanie środowiska produkcyjnego kopii zapasowej w przypadku awarii środowiska podstawowego. Środowisko może być środowiskiem Azure DevOps Environment lub inną lokalizacją, taką jak inny dostawca usług w chmurze. Zwiększa to ogólną niezawodność i dostępność aplikacji. Możesz również chcieć mieć alternatywne środowisko wdrażania na potrzeby odzyskiwania po awarii lub testowania i walidacji. Aby zapoznać się z bardziej skomplikowanymi strategiami wdrożeniowymi, zobacz Zadania wdrożeniowe oraz Dodawanie etapów, zależności i warunków.

Etap Rollback zapewnia siatkę bezpieczeństwa, aby przywrócić aplikację do wcześniej stabilnego stanu, jeśli coś pójdzie nie tak podczas lub po wdrożeniu. Może to być spowodowane niepowodzeniem wdrożenia, usterką, wymaganiami dotyczącymi zgodności, odzyskiwaniem po awarii lub innym problemem. Etap wycofywania jest niezbędny do utrzymania stabilności i niezawodności aplikacji.

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

Wyświetl cały potok YAML

Oto cały pipeline ze wszystkimi wymienionymi etapami.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build Stage'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    steps:
    - script: |
        echo "Restoring project dependencies..."
      displayName: 'Restore dependencies'
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'

- stage: Test
  displayName: 'Test Stage'
  dependsOn: Build
  isSkippable: false
  jobs:
  - job: TestJob
    displayName: 'Test Job'
    steps:
    - script: |
        echo "Running unit tests..."
      displayName: 'Run unit tests'


- stage: DeployToStaging
  displayName: 'Deploy to Staging'
  dependsOn: Test
  jobs:
  - job: DeployStagingJob
    displayName: 'Deploy to Staging Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        echo "Build staging job..."
      displayName: 'Build and deploy to staging'

  - job: DeployStagingJobWithValidation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    displayName: 'Deploy to Staging Job'
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the stage configuration and resume'
        onTimeout: 'resume'

- stage: DeployToProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployToStaging
  lockBehavior: sequential
  condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/main', 'refs/heads/release'))
  jobs:
  - job: DeployProductionJob
    displayName: 'Deploy to Production Job'
    steps:
    - script: |
        echo "Deploying to production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'
  - job: waitForValidation
    displayName: Wait for external validation
    pool: server
    timeoutInMinutes: 4320 # job times out in 3 days
    steps:
    - task: ManualValidation@1
      timeoutInMinutes: 1440 # task times out in 1 day
      inputs:
        notifyUsers: user@example.com
        instructions: 'Please validate the build configuration and resume'
        onTimeout: 'resume'

- stage: DeployToAlternateProduction
  displayName: 'Deploy to Alternate Production'
  condition: succeeded()
  trigger: manual
  jobs:
  - job: DeployAlternateProductionJob
    displayName: 'Deploy to Alternate Production Job'
    steps:
    - script: |
        echo "Deploying to alternate production..."
        # Add your deployment commands here
      displayName: 'Run deployment commands'

- stage: Rollback
  displayName: 'Rollback Stage'
  trigger: manual
  jobs:
  - job: RollbackJob
    displayName: 'Rollback Job'
    steps:
    - script: |
        echo "Rolling back the deployment..."
        # Add your rollback commands here
      displayName: 'Run rollback commands'

Następne kroki

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

  • Last updated on