Ćwiczenie — dodawanie wielu środowisk do przepływu pracy

7 min

Teraz możesz zaktualizować przepływ pracy w celu wdrożenia w środowiskach testowych i produkcyjnych. W tej jednostce zaktualizujesz przepływ pracy, aby używał nazywanych przepływów pracy, co pozwoli na ponowne użycie zadań w różnych środowiskach.

Podczas tego procesu wykonasz następujące czynności:

Dodaj przepływ pracy wielokrotnego użytku dla zadania lint.
Dodaj przepływ pracy wielokrotnego użytku, który definiuje zadania wymagane do wdrożenia w dowolnym środowisku.
Zaktualizuj przepływ pracy, aby używał nazywanych przepływów pracy.
Uruchom przepływ pracy i wyświetl wyniki.

Dodaj przepływ pracy wielokrotnego użytku dla zadania lintowania

Zadanie lint wykonywane jest tylko raz podczas przebiegu przepływu pracy, niezależnie od liczby środowisk, do których jest on wdrażany. W związku z tym nie musisz używać wywoływanego przepływu pracy dla zadania lint. Jednak aby główny plik definicji przepływu pracy był prosty i łatwy do odczytania, decydujesz się zdefiniować zadanie lint w osobnym pliku przepływu pracy.

W programie Visual Studio Code utwórz nowy plik w folderze .github/workflows o nazwie lint.yml.

Wklej następującą definicję przepływu pracy do pliku:

name: lint

on:
  workflow_call:

jobs:
  lint:
    name: Lint code
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Lint code
      run: |
        az bicep build --file deploy/main.bicep

Zadanie lint jest takie samo jak zadanie lint już w przepływie pracy, ale teraz znajduje się w osobnym pliku przepływu pracy.

Zapisz zmiany i zamknij plik.

Dodaj przepływ pracy wielokrotnego użytku do wdrożenia

Utwórz przepływ pracy wielokrotnego użytku, który definiuje wszystkie zadania wymagane do wdrożenia poszczególnych środowisk. Użyjesz danych wejściowych i tajnych danych, aby określić ustawienia, które mogą się różnić między środowiskami.

Utwórz nowy plik w folderze .github/workflows o nazwie deploy.yml.

Ten plik reprezentuje wszystkie działania wdrażania, które są uruchamiane dla każdego środowiska.
Wklej do pliku następującą nazwę przepływu pracy, wyzwalacz, dane wejściowe i wpisy tajne:
```
name: deploy

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
      resourceGroupName:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true
```
Notatka

Gdy zaczniesz pracować z plikiem YAML w programie Visual Studio Code, mogą pojawić się czerwone zygzakowate podkreślenia informujące o problemie. Dzieje się tak, ponieważ rozszerzenie programu Visual Studio Code dla plików YAML czasami niepoprawnie odgaduje schemat pliku.

Możesz zignorować problemy zgłaszane przez rozszerzenie. Jeśli wolisz, możesz dodać następujący kod na początku pliku, aby pominąć odgadywanie rozszerzenia:
```
# yaml-language-server: $schema=./deploy.yml
```

Poniżej tajemnic wklej definicję zadania weryfikacji:

jobs:
  validate:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v3
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - if: inputs.environmentType != 'Production'
       uses: azure/arm-deploy@v1
       name: Run preflight validation
       with:
         deploymentName: ${{ github.run_number }}
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         deploymentMode: Validate
     - if: inputs.environmentType == 'Production'
       uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         additionalArguments: --what-if

Zwróć uwagę, że do zadań jest zastosowany warunek. Walidacja wstępna jest uruchamiana tylko w środowiskach nieprodukcyjnych. Operacja typu "co jeśli" działa tylko w środowisku produkcyjnym. W poprzednim module w ścieżce szkoleniowej użyto oddzielnych zadań dla tych operacji, ale w tym miejscu połączysz je, aby uprościć przepływ pracy.

Wskazówka

Pliki YAML są wrażliwe na wcięcia. Bez względu na to, czy wpiszesz, czy wklejasz ten kod, upewnij się, że wcięcie jest poprawne. W dalszej części tego ćwiczenia zobaczysz kompletną definicję przepływu pracy YAML, aby sprawdzić, czy plik jest zgodny.

Poniżej zadania weryfikacji wklej definicję zadania wdrażania:

deploy:
  needs: validate
  environment: ${{ inputs.environmentType }}
  runs-on: ubuntu-latest
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ inputs.resourceGroupName }}
      template: ./deploy/main.bicep
      parameters: >
        environmentType=${{ inputs.environmentType }}

Poniżej zadania wdrażania wklej definicję zadania testu dymnego:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Sprawdź, czy plik deploy.yml wygląda teraz jak w poniższym przykładzie:

name: deploy

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
      resourceGroupName:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

jobs:
  validate:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v3
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - if: inputs.environmentType != 'Production'
       uses: azure/arm-deploy@v1
       name: Run preflight validation
       with:
         deploymentName: ${{ github.run_number }}
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         deploymentMode: Validate
     - if: inputs.environmentType == 'Production'
       uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ inputs.resourceGroupName }}
         template: ./deploy/main.bicep
         parameters: >
           environmentType=${{ inputs.environmentType }}
         additionalArguments: --what-if

  deploy:
    needs: validate
    environment: ${{ inputs.environmentType }}
    runs-on: ubuntu-latest
    outputs:
      appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      id: deploy
      name: Deploy Bicep file
      with:
        failOnStdErr: false
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ inputs.resourceGroupName }}
        template: ./deploy/main.bicep
        parameters: >
          environmentType=${{ inputs.environmentType }}

  smoke-test:
    runs-on: ubuntu-latest
    needs: deploy
    steps:
    - uses: actions/checkout@v3
    - run: |
        $container = New-PesterContainer `
          -Path 'deploy/Website.Tests.ps1' `
          -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
        Invoke-Pester `
          -Container $container `
          -CI
      name: Run smoke tests
      shell: pwsh

Zapisz zmiany w pliku.

Aktualizowanie definicji przepływu pracy w celu używania szablonów

Otwórz plik workflow.yml w folderze .github/workflows.
Usuń zawartość sekcji env:, w tym dwie zmienne środowiskowe. Zastąpisz je zmiennymi specyficznymi dla środowiska wkrótce.
Usuń zawartość definicji zadania lint: i zastąp ją następującym kodem, aby użyć utworzonego wcześniej pliku lint.yml:
```
# Lint the Bicep file.
lint:
  uses: ./.github/workflows/lint.yml
```
Usuń wszystko w pliku poniżej zadania lint, które zaktualizowałeś.

W dolnej części pliku dodaj następujący kod, aby wdrożyć go w środowisku testowym:

# Deploy to the test environment.
deploy-test:
  uses: ./.github/workflows/deploy.yml
  needs: lint
  with:
    environmentType: Test
    resourceGroupName: ToyWebsiteTest
  secrets:
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Poniżej właśnie dodanego kodu dodaj następujący kod, aby wdrożyć go w środowisku produkcyjnym:
```
# Deploy to the production environment.
deploy-production:
  uses: ./.github/workflows/deploy.yml
  needs: deploy-test
  with:
    environmentType: Production
    resourceGroupName: ToyWebsiteProduction
  secrets:
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
```
Zaktualizowany przepływ pracy uruchamia operację lint raz. Następnie używa przepływu pracy o nazwie deploy.yml, wywoływanego dwa razy: dla każdego środowiska. Dzięki temu definicja przepływu pracy jest jasna i łatwa do zrozumienia. Komentarze w pliku YAML identyfikują środowisko docelowe każdego zadania.

Sprawdź, czy plik workflow.yml wygląda następująco:

name: deploy-toy-website-environments
concurrency: toy-company

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:

  # Lint the Bicep file.
  lint:
    uses: ./.github/workflows/lint.yml

  # Deploy to the test environment.
  deploy-test:
    uses: ./.github/workflows/deploy.yml
    needs: lint
    with:
      environmentType: Test
      resourceGroupName: ToyWebsiteTest
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  # Deploy to the production environment.
  deploy-production:
    uses: ./.github/workflows/deploy.yml
    needs: deploy-test
    with:
      environmentType: Production
      resourceGroupName: ToyWebsiteProduction
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Zapisz zmiany.
Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Add reusable workflows"
git push
```
Ponieważ jest to pierwsze przesłanie do repozytorium, możesz zostać poproszony o zalogowanie się.

W systemie Windows wpisz 1 do uwierzytelniania przy użyciu przeglądarki internetowej, a następnie wybierz pozycję Wprowadź.

W systemie macOS wybierz pozycję Autoryzuj.
Zostanie wyświetlone okno przeglądarki. Może być konieczne ponowne zalogowanie się do usługi GitHub. Wybierz pozycję Autoryzuj.

Wyświetlanie przebiegu przepływu pracy

W przeglądarce przejdź do Actions.

Pierwszy przebieg przepływu pracy z etykietą Początkowe zatwierdzeniejest wyświetlany jako błąd. Usługa GitHub automatycznie uruchamiała przepływ pracy podczas tworzenia repozytorium. Nie powiodło się, ponieważ sekrety nie były gotowe w tym czasie. Możesz zignorować ten błąd.
Wybierz przepływ pracy deploy-toy-website-environments.
Wybierz najnowszy przebieg przepływu pracy.

Zwróć uwagę, że uruchomienie przepływu pracy pokazuje teraz wszystkie zadania zdefiniowane w plikach YAML.

Niektóre ostrzeżenia są wyświetlane w panelu adnotacji . Wszystkie te ostrzeżenia wynikają z tego, jak Bicep zapisuje komunikaty informacyjne w logu przepływu pracy. Możesz zignorować te ostrzeżenia.
Poczekaj na wstrzymanie przepływu pracy przed zadaniem wdrożenia produkcji / wdrożenia. Osiągnięcie tego punktu przez przepływ pracy może potrwać kilka minut.
Zatwierdź wdrożenie do środowiska produkcyjnego, wybierając przycisk Przeglądaj wdrożenia.
Wybierz środowisko produkcyjne, a następnie wybierz przycisk Zatwierdź i wdróż.

Poczekaj na zakończenie działania workflowu. Przepływ pracy zakończył się pomyślnie.
Wybierz Kod.
Wybierz wdrożenie produkcyjne .
Zwróć uwagę, że na ekranie wdrażania zostanie wyświetlone omówienie historii wdrożenia środowiska produkcyjnego.
Wybierz identyfikator zatwierdzenia.

Zauważ, że w usłudze GitHub jest wyświetlana lista zatwierdzeń uwzględnionych we wdrożeniu. Pomaga to zobaczyć zmiany w środowisku w czasie.
W przeglądarce przejdź do portalu Azure.
Przejdź do grupy zasobów ToyWebsiteProduction.
Na liście zasobów otwórz aplikację usługi Azure App Service.

Zwróć uwagę, że typ planu usługi App Service to S1.
Przejdź do aplikacji App Service w grupie zasobów ToyWebsiteTest.

Zwróć uwagę, że typ planu usługi App Service to F1. Dwa środowiska korzystają z różnych ustawień, które zdefiniowałeś w pliku Bicep.

Ćwiczenie — dodawanie wielu środowisk do przepływu pracy

Dodaj przepływ pracy wielokrotnego użytku dla zadania lintowania

Dodaj przepływ pracy wielokrotnego użytku do wdrożenia

Aktualizowanie definicji przepływu pracy w celu używania szablonów

Wyświetlanie przebiegu przepływu pracy

Opinia