Testowanie zasobów po wdrożeniu

6 min

Sprawdzając i wyświetlając podgląd wdrożenia Bicep, można było zapewnić pewność, że pliki Bicep zostaną pomyślnie wdrożone. Ale wdrożenie nie jest całą historią. Po zakończeniu wdrażania warto również sprawdzić, czy wdrożenie działa zgodnie z oczekiwaniami.

W tej lekcji poznasz testy, które można uruchomić po zakończeniu wdrażania. Dowiesz się również o wycofywaniu wdrożenia, jeśli wszystko nie jest wyświetlane zgodnie z oczekiwaniami.

Uruchamianie testów weryfikacyjnych kompilacji i testów ujemnych

Podczas definiowania zasobów w pliku Bicep twoim celem nie jest tylko tworzenie zasobów na platformie Azure. Jest to dostarczanie wartości w organizacji przy jednoczesnym spełnieniu wymagań organizacji. Podczas weryfikowania i wyświetlania podglądu plików Bicep zyskujesz pewność, że definicje zasobów są prawidłowe. Ale nie musisz wiedzieć, że zasoby rzeczywiście robią to, co chcesz.

Załóżmy na przykład, że wdrażasz nowy serwer logiczny Usługi Azure SQL przy użyciu przepływu pracy wdrażania Bicep. Definicja Bicep serwera jest prawidłowa, dlatego przekazuje zadania linter i walidacji wstępnej. Polecenie analizy co-jeżeli pokazuje, że serwer zostanie utworzony, co można oczekiwać. Wdrożenie zakończy się również pomyślnie. Jednak na końcu procesu wdrażania nadal może nie być uruchomiony serwer bazy danych, który jest gotowy do użycia. Przyczyny mogą obejmować:

Nie skonfigurowaliśmy reguł zapory, aby zezwolić na ruch sieciowy do serwera.
Włączono uwierzytelnianie firmy Microsoft Entra na serwerze, jeśli nie powinno być możliwe lub na odwrót.

Nawet w przypadku wdrażania podstawowych plików Bicep warto rozważyć, w jaki sposób można sprawdzić, czy wdrażane zasoby działają faktycznie i spełniają wymagania. Oto przykłady zastosowania tej zasady:

Podczas wdrażania witryny internetowej spróbuj uzyskać dostęp do aplikacji internetowej z przepływu pracy. Sprawdź, czy przepływ pracy łączy się z witryną internetową pomyślnie i otrzymuje prawidłowy kod odpowiedzi.
Podczas wdrażania sieci dostarczania zawartości (CDN) spróbuj nawiązać połączenie z zasobem za pośrednictwem sieci CDN. Sprawdź, czy przepływ pracy łączy się z usługą CDN pomyślnie i otrzymuje prawidłowy kod odpowiedzi.

Te testy są czasami nazywane testami weryfikacyjnymi kompilacji infrastruktury. Testowanie weryfikacyjne kompilacji to prosta forma testowania przeznaczona do wykrywania poważnych problemów we wdrożeniu.

Uwaga

Niektóre zasoby platformy Azure nie są łatwe do uzyskania dostępu z modułów uruchamianych w usłudze GitHub. Może być konieczne rozważenie użycia własnego modułu uruchamiającego testy weryfikacyjne kompilacji, jeśli wymagają one dostępu do zasobów za pośrednictwem sieci prywatnych.

Dobrym pomysłem jest również przeprowadzenie negatywnych testów. Testy negatywne pomagają potwierdzić, że zasoby nie mają niepożądanego zachowania. Na przykład podczas wdrażania maszyny wirtualnej warto używać usługi Azure Bastion do bezpiecznego łączenia się z maszyną wirtualną. Do przepływu pracy można dodać test ujemny, aby sprawdzić, czy nie można nawiązać połączenia z maszyną wirtualną bezpośrednio przy użyciu połączenia pulpitu zdalnego lub protokołu SSH.

Ważne

Celem tych testów nie jest sprawdzenie, czy Bicep prawidłowo wdrożył zasoby. Przy użyciu Bicep przyjmujesz założenie, że wdroży zasoby określone w plikach Bicep. Zamiast tego celem jest sprawdzenie, czy zasoby zdefiniowane przez Ciebie działają w danej sytuacji i spełniają twoje wymagania.

Uruchamianie testów z przepływów pracy usługi GitHub

Istnieje wiele sposobów uruchamiania testów w przepływie pracy. W tym module używamy narzędzia Pester, które jest narzędziem typu open source, które uruchamia testy napisane za pomocą programu PowerShell. Narzędzie Pester jest wstępnie zainstalowane w modułach uruchamianych w usłudze GitHub. Nie musisz wykonywać żadnych specjalnych czynności, aby używać ich w kroku skryptu.

Możesz użyć innej platformy testów, a nawet wybrać uruchamianie testów bez narzędzia testowego. Na przykład innym narzędziem testowym, które należy wziąć pod uwagę, jest psRule dla platformy Azure, które obejmuje wstępnie utworzone reguły i testy dla platformy Azure. Może ona uruchamiać walidację szablonów, a także uruchamiać testy względem wdrożonych zasobów platformy Azure. Link do elementu PSRule w podsumowaniu.

Po uruchomieniu testów z przepływu pracy wszystkie błędy testów powinny uniemożliwić kontynuowanie przepływu pracy. W następnym ćwiczeniu zobaczysz, jak można używać przepływów pracy z testami weryfikacyjnymi kompilacji infrastruktury.

Wyniki testów są zapisywane w dzienniku przepływu pracy. Witryna GitHub Marketplace zawiera również akcje inne niż Microsoft, które mogą wyświetlać i śledzić wyniki testów w czasie.

Przekazywanie danych między zadaniami

W przypadku dzielenia przepływu pracy na wiele zadań każda z nich ponosi własną odpowiedzialność, czasami trzeba przekazywać dane między tymi zadaniami. Na przykład jedno zadanie może utworzyć zasób platformy Azure, z którego musi pracować inne zadanie. Aby móc przekazywać dane, drugie zadanie musi znać nazwę utworzonego zasobu. Na przykład nasze zadanie testu weryfikacyjnego kompilacji musi uzyskać dostęp do zasobów wdrożonych przez zadanie wdrożenia.

Plik Bicep wdraża zasoby, aby mógł uzyskać dostęp do właściwości zasobu i opublikować je jako dane wyjściowe wdrożenia. Po uruchomieniu arm-deploy wdrożenia Bicep za pośrednictwem akcji ta akcja przechowuje te dane wyjściowe wdrożenia Bicep w danych wyjściowych kroku. Następnie zadanie przechowujące arm-deploy akcję może teraz opublikować te dane wyjściowe kroku jako dane wyjściowe zadania. Zadanie odwołuje się do właściwości kroku id , którą ustawiliśmy na deploy:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  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 website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Dostęp do danych wyjściowych zadania można uzyskać w dowolnym kolejnym zadaniu, o ile zależy od zadania, które generuje dane wyjściowe:

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

Możesz również przekazać dane wyjściowe ze skryptu przepływu pracy przy użyciu specjalnej składni. Link do dodatkowych informacji znajduje się w podsumowaniu.

Inne typy testów

Testy funkcjonalne i testy integracji są często używane do sprawdzania, czy wdrożone zasoby zachowują się zgodnie z oczekiwaniami. Na przykład test integracji może połączyć się z witryną internetową i przesłać testową transakcję, a następnie poczekać, aby potwierdzić, że transakcja zakończy się pomyślnie. Korzystając z testów integracji, możesz przetestować rozwiązanie kompilowane przez zespół wraz z infrastrukturą, na której działa. W przyszłym module zobaczysz, jak można dodać te typy testów do przepływu pracy.

Istnieje również możliwość uruchamiania innych typów testów z przepływu pracy wdrażania, w tym testów wydajnościowych i testów penetracyjnych zabezpieczeń. Te testy wykraczają poza zakres tego modułu, ale mogą one dodać wartość do zautomatyzowanego procesu wdrażania.

Wycofywanie lub wycofywanie

Załóżmy, że przepływ pracy pomyślnie wdraża zasoby, ale testy kończą się niepowodzeniem. Co należy zrobić?

Wcześniej w tym module przedstawiono, że funkcja GitHub Actions umożliwia tworzenie zadań wycofywania uruchamianych po awarii poprzedniego zadania. Za pomocą tego podejścia można utworzyć zadanie wycofywania, gdy zadanie testowe zgłosi nieoczekiwany wynik. Możesz również ręcznie wycofać zmiany lub ponownie uruchomić cały przepływ pracy, jeśli uważasz, że awaria była spowodowana tymczasowym problemem, który został już rozwiązany.

Uwaga

Po przesłaniu wdrożenia do usługi Azure Resource Manager możesz zażądać, aby usługa Resource Manager automatycznie ponownie uruchamiała ostatnie pomyślne wdrożenie, jeśli zakończy się niepowodzeniem. W tym celu użyj parametru --rollback-on-error podczas przesyłania wdrożenia przy użyciu polecenia interfejsu wiersza polecenia az deployment group create platformy Azure.

Możesz na przykład dodać zadanie wycofywania do przepływu pracy. Zadanie wycofywania jest uruchamiane, gdy zadanie testu kompilacji kończy się niepowodzeniem:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Zadanie zależy od zadania testu weryfikacyjnego kompilacji. Jest uruchamiany tylko wtedy, gdy test weryfikacyjny kompilacji zakończy się niepowodzeniem. Domyślnie funkcja GitHub Actions zatrzymuje przepływ pracy za każdym razem, gdy poprzednie zadanie zakończy się niepowodzeniem. Warunek if obejmuje always() sprawdzenie, aby zastąpić to zachowanie. always() Bez wyrażenia w wyrażeniu zadanie wycofywania jest pomijane za każdym razem, gdy poprzednie zadanie zakończy się niepowodzeniem.

Często trudno jest wypracować kroki, które powinno wykonać zadanie wycofywania. Ogólnie rzecz biorąc, wdrożenia Bicep są złożone i nie jest łatwe do wycofywania zmian. Szczególnie trudno jest wycofać wdrożenie, gdy wdrożenie zawiera inne składniki.

Załóżmy na przykład, że przepływ pracy wdraża plik Bicep definiujący bazę danych Azure SQL Database, a następnie dodaje dane do bazy danych. Czy po wycofaniu wdrożenia dane powinny zostać usunięte? Czy baza danych powinna zostać również usunięta? Trudno przewidzieć, jak każda awaria i każde wycofanie mogą mieć wpływ na uruchomione środowisko.

Z tego powodu wiele organizacji preferuje wycofywanie, co oznacza, że szybko naprawią przyczynę awarii, a następnie ponownie wdróż. Tworząc proces wdrażania zautomatyzowanego wysokiej jakości i postępując zgodnie ze wszystkimi najlepszymi rozwiązaniami poznanym w tych ścieżkach szkoleniowych, będzie można szybko rozwiązać problemy i ponownie wdrożyć pliki Bicep przy zachowaniu wysokiej jakości.

Napiwek