Ć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 lekcji zaktualizujesz przepływ pracy tak, aby używał nazywanych przepływami pracy, aby można było ponownie używać zadań w ś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.

Dodawanie przepływu pracy wielokrotnego użytku dla zadania lint

Zadanie lint odbywa się tylko raz podczas uruchamiania przepływu pracy, niezależnie od liczby środowisk wdrażanych w przepływie pracy. 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.

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

    Zrzut ekranu eksploratora programu Visual Studio Code z folderami dot github i przepływami pracy oraz plikiem lint dot YML.

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

  3. Zapisz zmiany i zamknij plik.

Dodawanie przepływu 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 wpisów tajnych, aby określić ustawienia, które mogą się różnić między środowiskami.

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

    Zrzut ekranu eksploratora programu Visual Studio Code z folderami dot github i przepływami pracy oraz plikiem deploy dot YML.

    Ten plik reprezentuje wszystkie działania wdrażania, które są uruchamiane dla każdego środowiska.

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

    Uwaga

    Gdy zaczniesz pracować z plikiem YAML w programie Visual Studio Code, mogą pojawić się czerwone ziewione wiersze 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

  3. Poniżej wpisów tajnych 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 warunek jest stosowany do zadań. Walidacja wstępna jest uruchamiana tylko w środowiskach nieprodukcyjnych. Operacja analizy warunkowej jest uruchamiana tylko dla środowiska produkcyjnego. 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.

    Napiwek

    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.

  4. 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 }}

  5. Poniżej zadania wdrażania wklej definicję zadania testu weryfikacyjnego kompilacji:

    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

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

  7. Zapisz zmiany w pliku.

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

  1. Otwórz plik workflow.yml w folderze .github/workflows.

  2. Usuń zawartość env: sekcji, w tym dwie zmienne środowiskowe. Zastąpisz je zmiennymi specyficznymi dla środowiska wkrótce.

  3. Usuń zawartość lint: definicji zadania 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

  4. Usuń wszystkie elementy w pliku poniżej zaktualizowanego zadania lint.

  5. 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 }}

  6. 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 zadanie lint raz. Następnie używa deploy.yml wywoływanego dwa razy przepływu pracy: raz na środowisko. Dzięki temu definicja przepływu pracy jest jasna i łatwa do zrozumienia. Komentarze w pliku YAML identyfikują środowisko docelowe każdego zadania.

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

  8. Zapisz zmiany.

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

  10. Ponieważ jest to pierwsze wypchnięcie do repozytorium, może zostać wyświetlony monit o zalogowanie się.

    W systemie Windows wpisz 1 , aby uwierzytelnić się przy użyciu przeglądarki internetowej, a następnie wybierz klawisz Enter.

    W systemie macOS wybierz pozycję Autoryzuj.

  11. Pojawi się okno przeglądarki. Może być konieczne ponowne zalogowanie się do usługi GitHub. Wybierz pozycję Autoryzuj.

Wyświetlanie przebiegu przepływu pracy

  1. W przeglądarce przejdź do pozycji Akcje.

    Pierwszy przebieg przepływu pracy z etykietą Zatwierdzenie początkowe jest wyświetlany jako błąd. Usługa GitHub automatycznie uruchamiała przepływ pracy podczas tworzenia repozytorium. Nie powiodło się, ponieważ wpisy tajne nie były w tym czasie gotowe. Możesz zignorować ten błąd.

  2. Wybierz przepływ pracy deploy-toy-website-environments.

  3. 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 Adnotacje . Wszystkie te ostrzeżenia są spowodowane tym, że Bicep zapisuje komunikaty informacyjne w dzienniku przepływu pracy. Możesz zignorować te ostrzeżenia.

  4. Poczekaj na wstrzymanie przepływu pracy przed wdrożeniem /wdrożeniem zadania. Osiągnięcie tego punktu przez przepływ pracy może potrwać kilka minut.

    Zrzut ekranu usługi GitHub przedstawiający przebieg przepływu pracy wstrzymany do zatwierdzenia.

  5. Zatwierdź wdrożenie w środowisku produkcyjnym, wybierając przycisk Przejrzyj wdrożenia .

  6. Wybierz środowisko produkcyjne, a następnie wybierz przycisk Zatwierdź i wdróż.

    Zrzut ekranu przedstawiający interfejs usługi GitHub przedstawiający stronę zatwierdzania przepływu pracy oraz przycisk Zatwierdź i wdróż.

    Poczekaj na zakończenie działania przepływu pracy. Przepływ pracy zakończy się pomyślnie.

  7. Wybierz pozycję Kod.

  8. Wybierz wdrożenie produkcyjne.

    Zrzut ekranu witryny GitHub przedstawiający środowisko strony kodowej z wyróżnionym środowiskiem produkcyjnym.

  9. Zwróć uwagę, że na ekranie wdrażania zostanie wyświetlone omówienie historii wdrożenia środowiska produkcyjnego.

    Zrzut ekranu usługi GitHub przedstawiający środowisko produkcyjne z historią wdrażania z pojedynczym wdrożeniem.

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

    Zrzut ekranu usługi GitHub przedstawiający szczegóły wdrożenia środowiska produkcyjnego z listą zatwierdzeń.

  11. W przeglądarce przejdź do witryny Azure Portal.

  12. Przejdź do grupy zasobów ToyWebsiteProduction .

  13. Na liście zasobów otwórz aplikację usługi aplikacja systemu Azure Service.

    Zrzut ekranu witryny Azure Portal przedstawiający aplikację produkcyjną witryny internetowej usługi App Services z aplikacjami do obsługi aplikacji i szczegóły jednostki SKU planu usługi App Service.

    Zwróć uwagę, że typ planu usługi App Service to S1.

  14. Przejdź do aplikacji App Service w grupie zasobów ToyWebsiteTest .

    Zwróć uwagę, że typ planu usługi App Service to F1. Te dwa środowiska używają różnych ustawień, zgodnie z definicją w pliku Bicep.