Wyświetlanie podglądu i zatwierdzanie wdrożenia

5 min

Znasz już etapy potoku i sposób dodawania etapu potoku w celu zweryfikowania kodu Bicep. Następnym krokiem w budowaniu zaufania do wdrożenia jest dodanie kolejnego etapu w celu sprawdzenia, co zmieni wdrożenie.

W tej lekcji dowiesz się więcej na temat używania polecenia analizy co-jeżeli w potoku. Dowiesz się również o dodawaniu zatwierdzeń, 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.

Po utworzeniu, zaktualizowaniu lub usunięciu zasobów 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, które zasoby zostaną 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 wystąpią w danym środowisku.

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

Diagram potoku, który zawiera etapy Lint, Validate i Preview. Etap wersji zapoznawczej wykonuje operację analizy warunkowej na platformie Azure.

Możesz użyć polecenia interfejsu wiersza polecenia platformy az deployment group what-if Azure z poziomu definicji potoku, aby uruchomić krok analizy co-jeżeli:

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

Napiwek

W tym module użyjemy interfejsu wiersza polecenia platformy Azure do uruchomienia operacji analizy co-jeżeli. Jeśli tworzysz własny potok oparty na programie PowerShell, możesz użyć New-AzResourceGroupDeployment polecenia cmdlet z przełącznikiem -Whatif lub użyć Get-AzResourceGroupDeploymentWhatIfResult polecenia cmdlet .

Operacja analizy co-jeżeli nie wprowadza żadnych zmian w środowisku. Zamiast tego opisuje zasoby, które zostaną utworzone lub usunięte, 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. Ta opinia jest nazywana szumem. Pracujemy nad ograniczeniem tych problemów, ale potrzebujemy Twojej pomocy, aby zgłosić te problemy.

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ć uruchomienie potoku.

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 usłudze Azure Pipelines ś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 skoncentrujemy się na możliwości dodawania ręcznych zatwierdzeń do potoku.

Jak już wiesz, używasz zadań do definiowania sekwencji kroków w ramach etapu potoku. W przypadku uwzględnienia środowisk w potoku należy użyć specjalnego typu zadania nazywanego zadaniem wdrożenia. Zadanie wdrożenia jest podobne do normalnego zadania, ale zapewnia pewne dodatkowe funkcje. Ta funkcja obejmuje definiowanie środowiska używanego przez zadanie wdrażania:

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Zwróć uwagę, że w definicji YAML zadania wdrożenia istnieją pewne kluczowe różnice w porównaniu z normalnym zadaniem:

Zamiast zaczynać się od słowa job, zadanie wdrożenia jest definiowane jako deployment.
Słowo environment kluczowe określa nazwę środowiska docelowego. W poprzednim przykładzie wdrożenie jest śledzone względem środowiska o nazwie MyAzureEnvironment.
Słowo strategy kluczowe określa, jak usługa Azure Pipelines uruchamia kroki wdrażania. Strategie wdrażania obsługują złożone procesy wdrażania, szczególnie w przypadku wielu środowisk produkcyjnych. W tym module używamy runOnce strategii wdrażania. Ta strategia działa podobnie do innych zadań, do których już używasz.

Kontrole etapów i zatwierdzenia

Po utworzeniu środowiska można zdefiniować kontrole. Sprawdzanie służy do weryfikowania warunków, które muszą zostać spełnione przed użyciem środowiska przez potok. Zatwierdzenie jest typem sprawdzania, który wymaga od człowieka ręcznego zatwierdzenia.

Kontrole są definiowane w środowisku, a nie potoku. Autorzy pliku YAML potoku nie mogą usunąć ani dodać tych testów i zatwierdzeń. Tylko administratorzy środowiska mogą zarządzać kontrolami i zatwierdzeniami.

W wielu organizacjach właściciel środowiska w usłudze Azure Pipelines jest osobą odpowiedzialną za wdrożone środowisko. Kontrole i zatwierdzenia pomagają zagwarantować, że odpowiednie osoby są zaangażowane w proces wdrażania.

Jak działają kontrole i zatwierdzenia?

Kontrole i zatwierdzenia są oceniane tuż przed rozpoczęciem etapu potoku. Gdy usługa Azure Pipelines ma uruchomić etap potoku, analizuje wszystkie używane zasoby potoku, w tym środowiska. Środowiska mogą mieć kontrole, które muszą być spełnione.

Zatwierdzenie jest jednym z typów kontroli. Podczas konfigurowania sprawdzania zatwierdzenia należy przypisać co najmniej jednego użytkownika, który musi zatwierdzić kontynuację potoku.

Usługa Azure Pipelines udostępnia również inne typy kontroli. Na przykład możesz wywołać interfejs API, aby uruchomić logikę niestandardową, kontrolować godziny pracy, w których można uruchomić etap, a nawet wysyłać zapytanie do usługi Azure Monitor, aby upewnić się, że wdrożenie zakończyło się pomyślnie. Omawiamy tylko kontrole zatwierdzeń w tym module, ale udostępniamy linki do dodatkowych informacji na temat kontroli w podsumowaniu.

Uwaga

Pule agentów i połączenia usług mogą również mieć skonfigurowane kontrole. Można również użyć specjalnego kroku nazywanego zadaniem zatwierdzania ręcznego. Jednak w tym module skupimy się na środowiskach i skojarzonych z nimi kontrolach.

Po rozpoczęciu potoku i osiągnięciu etapu wymagającego sprawdzenia zatwierdzenia przebieg potoku zostanie wstrzymany. Wszyscy użytkownicy, którzy zostali wyznaczeni jako osoby zatwierdzające, są wysyłani wiadomości w usłudze Azure DevOps i pocztą e-mail.

Osoby zatwierdzające mogą sprawdzać dzienniki potoku, takie jak zmiany wykryte przez operację analizy co-jeżeli. Na podstawie tych informacji zatwierdzają lub odrzucają zmianę. Jeśli zatwierdzi zmianę, potok zostanie wznowione. Jeśli odrzucają lub nie odpowiadają w konfigurowalnym przedziale czasu, etap kończy się niepowodzeniem.

Diagram potoku obejmującego etapy Lint, Validate, Preview i Deploy z sprawdzeniem zatwierdzenia przed etapem wdrażania.

Znaczenie dobrych praktyk

Funkcja środowisk w usłudze Azure Pipelines umożliwia łączenie wdrożeń ze środowiskiem, a następnie wdrożenie dziedziczy kontrole i zatwierdzenia zdefiniowane przez właściciela środowiska. Nie trzeba jednak wymagać, aby nowe potoki używały środowisk.

Ważne jest, aby Ty i Twoja organizacja ustalali dobre rozwiązania dotyczące przeglądania definicji potoku. Przykładem jest skonfigurowanie repozytorium w celu wymagania przeglądów żądań ściągnięcia w przypadku wszelkich zmian w gałęzi głównej przy użyciu zasad ochrony gałęzi. Więcej informacji na temat tej koncepcji znajdziesz w przyszłym module.

Można również dodawać kontrole i zatwierdzenia do połączeń usług, które zapewniają uzyskanie zatwierdzenia przed wdrożeniem może używać poświadczeń jednostki usługi. Jednak zatwierdzenia miałyby również wpływ na zdolność potoku do uruchamiania weryfikacji wstępnej i operacji analizy warunkowej, ponieważ wymagają one również połączenia z usługą.