Omówienie etapów potoku

Potoki umożliwiają zautomatyzowanie kroków procesu wdrażania. Proces może obejmować kilka logicznych grup zadań, które chcesz uruchomić. W tej jednostce nauczysz się o etapach potoków i jak ich używać do dodawania procesów kontroli jakości do wdrożeń Bicep.

Co to są etapy potoku?

Etapy pomagają podzielić potok na wiele bloków logicznych. Każdy etap może zawierać co najmniej jedno zadania. Zadania zawierają uporządkowaną listę kroków, które należy wykonać, na przykład uruchamianie skryptów wiersza polecenia.

Możesz użyć etapów w potoku, aby oznaczyć separację problemów. Na przykład podczas pracy z kodem Bicep walidacja kodu jest osobnym problemem przed wdrożeniem pliku Bicep. W przypadku korzystania z zautomatyzowanego potoku kompilowanie i testowanie kodu jest często nazywane ciągłą integracją (CI). Wdrażanie kodu w zautomatyzowanym potoku jest często nazywane ciągłym wdrażaniem (CD).

Podczas etapów ciągłej integracji sprawdzasz poprawność zmian wprowadzonych w kodzie. Etapy ciągłej integracji zapewniają gwarancję jakości. Można je uruchomić bez wpływu na środowisko produkcyjne.

W wielu językach programowania należy skompilować kod, zanim ktoś będzie mógł go uruchomić. Po wdrożeniu pliku Bicep jest on konwertowany lub transpilowany z pliku Bicep na JSON. Narzędzie wykonuje ten proces automatycznie. W większości sytuacji nie trzeba ręcznie kompilować kodu Bicep na szablony JSON w przepływie pracy. Nadal używamy terminu ciągła integracja , gdy mówimy o kodzie Bicep, ponieważ inne części ciągłej integracji nadal mają zastosowanie, takie jak walidacja kodu.

Po pomyślnym uruchomieniu etapów ciągłej integracji powinieneś zwiększyć swoją pewność, że wprowadzone zmiany również zostaną pomyślnie wdrożone. Na etapach CD Twój kod jest wdrażany we wszystkich środowiskach. Zwykle rozpoczynasz od testów i innych środowisk nieprodukcyjnych, a następnie przechodzisz do środowisk produkcyjnych. W tym module wdrożysz je w jednym środowisku. W przyszłym module dowiesz się, jak rozszerzyć potok wdrażania w celu wdrożenia w wielu środowiskach, takich jak środowiska nieprodukcyjne i produkcyjne.

Etapy są uruchamiane w sekwencji. Możesz kontrolować, jak i kiedy poszczególne etapy są uruchamiane. Można na przykład skonfigurować etapy ciągłego wdrażania tak, aby działały dopiero po pomyślnym uruchomieniu etapów ciągłej integracji. Możesz też mieć wiele kroków ciągłej integracji, które muszą być uruchamiane w określonej kolejności, na przykład w celu skompilowania kodu, a następnie jego przetestowania. Można również uwzględnić etap wycofywania uruchamiany tylko wtedy, gdy poprzednie etapy wdrażania kończą się niepowodzeniem.

Przesunięcie w lewo

Za pomocą etapów można zweryfikować jakość kodu przed jego wdrożeniem. Używanie tych etapów jest czasami nazywane przesunięciem w lewo.

Rozważ oś czasu działań wykonywanych podczas pisania kodu. Oś czasu rozpoczyna się od faz planowania i projektowania. Następnie przechodzi do fazy budynku i testowania. Na koniec wdrażasz i obsługujesz rozwiązanie. Na poniższym diagramie przedstawiono te etapy na osi czasu.

Jest to dobrze zrozumiała reguła w tworzeniu oprogramowania, że im wcześniej w procesie znajdziesz błąd (im bliżej lewej strony osi czasu), tym łatwiejsza, szybsza i tańsza jest jego naprawa. Im później w trakcie procesu zostanie przechwycenie błędu, tym trudniej jest rozwiązać problem.

Dlatego celem jest przesunięcie odnajdywania problemów w kierunku lewej strony diagramu. W tym module dowiesz się, jak dodać więcej weryfikacji i testowania do potoku w miarę postępu.

Przed rozpoczęciem wdrażania można nawet dodać walidację. Podczas pracy z narzędziami, takimi jak Azure DevOps, pull requesty zwykle reprezentują zmiany, które ktoś z zespołu chce wprowadzić do kodu w gałęzi głównej. Warto utworzyć kolejny potok, który automatycznie uruchamia kroki ciągłej integracji podczas procesu przeglądu dla żądania ściągnięcia. Ta technika pomaga sprawdzić, czy kod nadal działa, nawet w przypadku proponowanych zmian. Jeśli walidacja zakończy się pomyślnie, masz pewność, że zmiana nie spowoduje problemów podczas scalania z gałęzią główną. Jeśli sprawdzanie zakończy się niepowodzeniem, wiesz, że jest więcej pracy do zrobienia, zanim pull request będzie gotowy do scalenia.

Definiowanie etapu potoku

Każdy potok zawiera co najmniej jeden etap. Jeśli potok ma tylko jeden etap, nie musisz jawnie go definiować. Usługa Azure Pipelines automatycznie je definiuje. Jeśli masz wiele etapów w potoku, musisz zdefiniować każdy z nich. Etapy są uruchamiane w określonej sekwencji.

Załóżmy, że utworzono plik Bicep, który należy wdrożyć dwa razy: raz w infrastrukturze w Stany Zjednoczone i raz w infrastrukturze w Europie. Zanim wdrożysz plik, zweryfikuj kod Bicep. Oto ilustracja przedstawiająca potok wieloestrowy, który definiuje ten proces:

Zwróć uwagę, że ten przykład ma trzy etapy. Etap Weryfikacji jest podobny do etapu ciągłej integracji. Etapy DeployUS i DeployEurope są uruchamiane w następnej kolejności. Każdy z nich wdraża kod w jednym ze środowisk.

Poniżej przedstawiono sposób definiowania etapów w pliku YAML potoku:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

Kontrolowanie sekwencji etapów

Domyślnie etapy są uruchamiane w zdefiniowanej kolejności. Etap jest uruchamiany tylko wtedy, gdy poprzedni etap zakończy się pomyślnie. Możesz dodać zależności między etapami, aby zmienić kolejność.

Kontynuując poprzedni przykład, wyobraź sobie, że chcesz uruchomić oba wdrożenia równolegle, w następujący sposób:

Zależności między etapami można określić przy użyciu słowa kluczowego dependsOn :

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

Gdy używasz słowa kluczowego dependsOn , usługa Azure Pipelines czeka na pomyślne zakończenie etapu zależnego przed rozpoczęciem następnego etapu. Jeśli usługa Azure Pipelines wykryje, że wszystkie zależności dla wielu etapów są spełnione, można uruchomić te etapy równolegle.

Możesz chcieć uruchomić etap, gdy poprzedni etap zakończy się niepowodzeniem. Oto na przykład inny potok. Jeśli wdrożenie zakończy się niepowodzeniem, etap o nazwie Wycofywanie zostanie uruchomiony natychmiast potem:

Możesz użyć słowa kluczowego condition , aby określić warunek, który ma zostać spełniony przed uruchomieniem etapu:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

W poprzednim przykładzie, gdy wszystko pójdzie dobrze, usługa Azure Pipelines najpierw uruchamia etap Validate , a następnie uruchamia etap Wdrażanie . Pomija etap wycofywania. Jeśli jednak etap wdrażania zakończy się niepowodzeniem, usługa Azure Pipelines uruchamia etap wycofywania . Więcej informacji na temat wycofywania znajdziesz w dalszej części tego modułu.

Każde zadanie jest uruchamiane na nowym agencie. Oznacza to, że każde zadanie rozpoczyna się od czystego środowiska, więc w każdym zadaniu zwykle trzeba wyewidencjonować kod źródłowy jako pierwszy krok.

Etapy wdrażania Bicep

Typowy potok wdrażania Bicep zawiera kilka etapów. W miarę przechodzenia potoku przez etapy celem jest coraz bardziej pewność, że późniejsze etapy odniosą sukces. Poniżej przedstawiono typowe etapy potoku wdrażania Bicep:

1. Lint: użyj lintera Bicep, aby sprawdzić, czy plik Bicep jest poprawnie sformułowany i nie zawiera żadnych oczywistych błędów.
2. Sprawdź: użyj procesu walidacji preflight Azure Resource Manager, aby sprawdzić, czy wystąpią problemy podczas wdrażania.
3. Podgląd: skorzystaj z polecenia co-jeżeli, aby zweryfikować listę zmian, które zostaną zastosowane do twojego środowiska Azure. Osoba powinna ręcznie przejrzeć wyniki analizy typu what-if i zatwierdzić proces przed jego kontynuowaniem.
4. Wdrażanie: prześlij wdrożenie do usługi Resource Manager i poczekaj na zakończenie.
5. Test sprawdzający: Uruchom podstawowe testy po wdrożeniu na niektóre z ważnych wdrożonych zasobów. Te przeglądy są nazywane testami wstępnymi infrastruktury.

Twoja organizacja może mieć inną sekwencję etapów lub może być konieczne zintegrowanie wdrożeń Bicep z potokiem, który wdraża inne składniki. Po zrozumieniu, jak działają etapy, możesz zaprojektować potok zgodnie z potrzebami.

W tym module dowiesz się więcej na temat etapów wymienionych tutaj, a następnie stopniowo utworzysz potok zawierający poszczególne etapy. Dowiesz się również:

• Jak potoki zatrzymują proces wdrażania, jeżeli dojdzie do czegoś nieoczekiwanego podczas któregokolwiek z wcześniejszych etapów.
• Jak skonfigurować potok do wstrzymania do momentu ręcznego sprawdzenia, co się stało w poprzednim etapie.