Wyświetlanie podglądu i zatwierdzanie wdrożenia

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 spodziewasz. 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:

Aby uruchomić krok what-if, możesz użyć polecenia Azure CLI w definicji pipeline'u.

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

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. Tą opinię nazywa się szumem. Pracujemy nad ograniczeniem tych problemów. Problemy można zgłaszać tutaj.

Po obejrzeniu rezultatów analizy co-jeżeli możesz określić, czy kontynuować wdrażanie. Ten krok zazwyczaj polega na tym, że człowiek przegląda dane wyjściowe z polecenia "co-jeżeli" i następnie podejmuje decyzję, czy zidentyfikowane zmiany są uzasadnione. Jeśli recenzent zdecyduje, że zmiany są uzasadnione, może ręcznie zatwierdzić uruchomienie potoku.

Ś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 "pipeline'u". W przypadku uwzględnienia środowisk w pipeline'u 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żyjesz strategii runOnce 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 rodzajem kontroli, który wymaga od człowieka manualnego 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 zasoby potoku używane przez etap, 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 recenzenta, 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ć zapytania do usługi Azure Monitor, aby upewnić się, że wdrożenie zakończyło się pomyślnie. W tym module omówiono tylko kontrole zatwierdzeń, ale podsumowanie modułu zawiera linki do dodatkowych informacji na temat kontroli.

Po rozpoczęciu potoku i osiągnięciu etapu wymagającego sprawdzenia zatwierdzenia przebieg potoku zostanie wstrzymany. Wszyscy recenzenci, którzy zostali wyznaczeni jako osoby zatwierdzające, są wysyłane 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.

Znaczenie dobrych praktyk

Funkcja środowisk w usłudze Azure Pipelines umożliwia łączenie wdrożeń ze środowiskiem. 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 tym, jak wdrożenie będzie mogło użyć poświadczeń jednostki usługowej. Jednak zatwierdzenia miałyby również wpływ na możliwość uruchamiania weryfikacji wstępnej potoku i operacji analizy warunkowej, ponieważ wymagają one również połączenia z usługą.

Możesz użyć innego, oddzielnego połączenia usługi dla etapu analizy warunkowej z własną jednostką usługi. Jednostka usługi używana na potrzeby etapów wstępnego i walidacji musi mieć zdefiniowaną niestandardową rolę platformy Azure, aby mieć pewność, że ma minimalne uprawnienia, które musi wykonać.