Wyświetlanie podglądu i zatwierdzanie wdrożenia

5 min

Znasz już zadania przepływu pracy i dowiesz się, jak można dodać zadanie przepływu pracy w celu zweryfikowania kodu Bicep. Następnym krokiem w budowaniu zaufania do wdrożenia jest dodanie kolejnego zadania w celu sprawdzenia, co zmieni wdrożenie.

W tej lekcji dowiesz się, jak używać polecenia analizy co-jeżeli w przepływie pracy. Dowiesz się również o dodawaniu reguł ochrony środowiska, aby mieć możliwość ręcznego zweryfikowania danych wyjściowych polecenia przed uruchomieniem wdrożenia.

Operacja analizy co-jeżeli

Plik Bicep opisuje stan, w którym środowisko platformy Azure ma znajdować się na końcu wdrożenia. Po przesłaniu wdrożenia usługa Azure Resource Manager zmienia środowisko platformy Azure tak, aby było zgodne ze stanem opisanym w pliku Bicep.

Wdrożenie może spowodować wdrożenie nowych zasobów w środowisku lub zaktualizowanie istniejących zasobów. Po uruchomieniu wdrożenia w trybie pełnym może nawet spowodować usunięcie istniejących zasobów.

Za każdym razem, gdy zasoby są tworzone, aktualizowane lub usuwane, istnieje ryzyko, że elementy mogą ulec zmianie w sposób, którego się nie spodziewano. Dobrym rozwiązaniem jest dodanie dodatkowego kroku w celu sprawdzenia, co dokładnie zostanie utworzone, zaktualizowane i usunięte. Ta weryfikacja zwiększa wartość procesu automatyzacji. Podczas wdrażania w środowisku produkcyjnym ważne jest, aby potwierdzić wszelkie zmiany, które mają miejsce w danym środowisku.

Usługa Resource Manager udostępnia operację analizy co-jeżeli, którą można uruchomić w pliku Bicep w ramach zadania przepływu pracy:

Diagram przepływu pracy, który zawiera zadania Lint, Validate i Preview. Zadanie w wersji zapoznawczej wykonuje operację analizy warunkowej na platformie Azure.

Akcja arm-deploy obsługuje wyzwalanie operacji analizy co-jeżeli przy użyciu additionalArguments właściwości :

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - 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
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

Wyróżniony kod jest odpowiednikiem uruchamiania wdrożenia przy użyciu interfejsu wiersza polecenia platformy Azure z dołączonym argumentem --what-if .

Operacja analizy co-jeżeli nie wprowadza żadnych zmian w środowisku. Zamiast tego opisuje zasoby, które zostaną utworzone, właściwości zasobu, które zostaną zaktualizowane, oraz zasoby, które zostaną usunięte.

Co-jeśli czasami pokazuje, że zasób zmieni się, gdy rzeczywiście nie nastąpi żadna zmiana. Ten typ danych wyjściowych jest nazywany szumem. Pracujemy nad ograniczeniem tych problemów, ale potrzebujemy Twojej pomocy. Zgłoś problemy warunkowe.

Po wyświetleniu danych wyjściowych operacji analizy co-jeżeli możesz określić, czy kontynuować wdrażanie. Ten krok zazwyczaj obejmuje przejrzenie danych wyjściowych z polecenia analizy co-jeżeli, a następnie podjęcie decyzji o tym, czy zidentyfikowane zmiany są uzasadnione. Jeśli recenzent zdecyduje, że zmiany są uzasadnione, mogą ręcznie zatwierdzić przebieg przepływu pracy.

Aby dowiedzieć się więcej o poleceniu analizy co-jeżeli, zobacz moduł Microsoft Learn (wersja zapoznawcza) zmiany wdrażania platformy Azure przy użyciu analizy co-jeżeli.

Środowiska

W funkcji GitHub Actions środowisko reprezentuje miejsce wdrożenia rozwiązania. Środowiska zapewniają funkcje, które ułatwiają pracę ze złożonymi wdrożeniami. W przyszłym module dowiesz się więcej o środowiskach i ich funkcjach. Na razie skupiamy się na możliwości dodawania wymaganych recenzentów do przepływu pracy.

Środowisko można utworzyć przy użyciu interfejsu internetowego usługi GitHub. Środowiska można tworzyć podczas pracy z publicznym repozytorium GitHub lub w przypadku korzystania z konta usługi GitHub Enterprise.

Po utworzeniu środowiska możesz odwoływać się do niego w dowolnych zadaniach w przepływie pracy:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Uwaga

Gdy tożsamość obciążenia przepływu pracy wdrażania współdziała z usługą Resource Manager w środowisku, wymaga poświadczeń federacyjnych skonfigurowanych z nazwą środowiska. Więcej informacji na temat środowisk znajdziesz w przyszłych modułach. Po uruchomieniu ćwiczeń dla tego modułu utworzysz niezbędne poświadczenia federacyjne.

Reguły ochrony środowiska

Po utworzeniu środowiska można zdefiniować reguły ochrony. Reguły ochrony służą do weryfikowania warunków, które muszą zostać spełnione przed wykonaniem kroku w środowisku. Wymagana reguła ochrony recenzentów to typ sprawdzania, który wymaga od człowieka ręcznego zatwierdzenia.

Reguły ochrony są definiowane w środowisku, a nie w przepływie pracy. Autorzy pliku YAML przepływu pracy nie mogą usunąć ani dodać tych reguł ochrony. Tylko administratorzy repozytorium lub właściciel konta mogą zarządzać środowiskami i ich regułami ochrony.

Reguły ochrony środowiska pomagają zapewnić, że odpowiednie osoby są zaangażowane w proces wdrażania.

Jak działają reguły ochrony środowiska?

Po skojarzeniu środowiska z krokiem reguły ochrony środowiska są oceniane tuż przed rozpoczęciem kroku.

Wymagany recenzent jest jednym z typów reguł ochrony. Podczas konfigurowania wymaganej reguły ochrony recenzenta należy przypisać co najmniej jednego użytkownika usługi GitHub, którzy muszą zatwierdzić kontynuację przepływu pracy.

Środowiska zapewniają też inne typy reguł ochrony. Można na przykład ograniczyć gałęzie usługi Git, które można wdrożyć w określonych środowiskach. W tym module omówimy tylko wymaganą regułę recenzentów, ale udostępniamy linki do dodatkowych informacji o innych regułach ochrony w podsumowaniu.

Po rozpoczęciu przepływu pracy i osiągnięciu kroku wymagającego recenzenta przebieg przepływu pracy zostanie wstrzymany. Wszyscy użytkownicy, którzy są wyznaczeni jako recenzenci, są wysyłani wiadomości w usłudze GitHub i pocztą e-mail.

Recenzenci mogą sprawdzać dzienniki przepływu pracy, takie jak zmiany wykryte przez operację analizy co-jeżeli. Na podstawie tych informacji zatwierdzają lub odrzucają zmianę. Jeśli zatwierdzi zmianę, przepływ pracy zostanie wznowione. Jeśli odrzucają lub nie odpowiadają w okresie przekroczenia limitu czasu, zadanie kończy się niepowodzeniem.

Diagram przepływu pracy, który zawiera zadania Lint, Validate, Preview i Deploy z sprawdzeniem zatwierdzenia przed zadaniem wdrażania.

Znaczenie dobrych praktyk

Funkcja środowisk w usłudze GitHub umożliwia łączenie wdrożeń ze środowiskiem, a następnie wdrożenie dziedziczy reguły ochrony zdefiniowane przez administratora środowiska. Nie trzeba jednak wymagać, aby nowe przepływy pracy używały środowisk.

Ważne jest, aby organizacja ustanowiła dobre rozwiązania dotyczące przeglądania definicji przepływu pracy. Na przykład skonfiguruj repozytorium, aby wymagać przeglądów żądań ściągnięcia na wszelkie zmiany w gałęzi głównej przy użyciu reguł ochrony gałęzi. Więcej informacji na temat tej koncepcji znajdziesz w przyszłym module.