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 lekcji dowiesz się więcej o etapach potoków i sposobie ich używania do dodawania procesów kontroli jakości do wdrożeń Bicep.
Co to są etapy potoku?
Etapy ułatwiają podzielenie potoku 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.
Etapy mogą być używane w potoku do oznaczania separacji 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).
Na etapach ciągłej integracji sprawdzasz poprawność zmian wprowadzonych w kodzie. Etapy ciągłej integracji zapewniają gwarancję jakości. Można je uruchamiać bez wpływu na środowisko produkcyjne na żywo.
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 do szablonów JSON w potoku. 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 należy zwiększyć pewność, że wprowadzone zmiany również zostaną pomyślnie wdrożone. Na etapach ciągłego wdrażania kod zostanie wdrożony w każdym środowisku. Zazwyczaj zaczynasz od testowania i innych środowisk nieprodukcyjnych i przechodzisz do środowisk produkcyjnych. W tym module wdrożymy 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 etapów ciągłej integracji, które muszą być uruchamiane w sekwencji, na przykład w celu skompilowania kodu, a następnie przetestowania go. Można również uwzględnić etap wycofywania uruchamiany tylko wtedy, gdy poprzednie etapy wdrażania nie powiodły się.
Przesunięcie w lewo
Za pomocą etapów można zweryfikować jakość kodu przed jego wdrożeniem. Te etapy są 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 wdrożysz rozwiązanie, a następnie musisz je obsługiwać.
Jest to dobrze zrozumiała reguła w tworzeniu oprogramowania, którą wcześniej w procesie znajdujesz błąd (bliżej lewej strony osi czasu), łatwiejsze, szybsze i tańsze jest naprawienie. Im później w trakcie procesu zostanie przechwycenie błędu, tym trudniej jest rozwiązać problem.
Dlatego celem jest przesunięcie odnajdywania problemów po lewej stronie powyższego 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, żądania ściągnięcia 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 istnieje więcej pracy do wykonania, zanim żądanie ściągnięcia będzie gotowe do scalenia.
Ważne
Automatyczne sprawdzanie poprawności i testy są tak skuteczne, jak testy, które piszesz. Ważne jest, aby wziąć pod uwagę kwestie, które należy przetestować, oraz czynności, które należy wykonać, aby mieć pewność, że wdrożenie jest prawidłowe.
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. Przed wdrożeniem należy zweryfikować 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. Następnie zostaną uruchomione etapy DeployUS i DeployEurope. 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 zostały spełnione, można uruchomić te etapy równolegle.
Uwaga
W rzeczywistości etapy i zadania są uruchamiane równolegle tylko wtedy, gdy masz wystarczająco dużo agentów, aby uruchamiać wiele zadań jednocześnie. W przypadku korzystania z agentów hostowanych przez firmę Microsoft może być konieczne zakup dodatkowych zadań równoległych, aby to osiągnąć.
Czasami chcesz 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 wykonywane na nowym agencie. Oznacza to, że każde zadanie rozpocznie 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:
- Lint: użyj lintera Bicep, aby sprawdzić, czy plik Bicep jest poprawnie sformułowany i nie zawiera żadnych oczywistych błędów.
- Weryfikacja: użyj procesu weryfikacji wstępnej usługi Azure Resource Manager, aby sprawdzić, czy występują problemy, które mogą wystąpić podczas wdrażania.
- Wersja zapoznawcza: użyj polecenia analizy co-jeżeli, aby zweryfikować listę zmian, które zostaną zastosowane w środowisku platformy Azure. Poproś człowieka o ręczne przejrzenie wyników analizy co-jeżeli i zatwierdzenie potoku w celu kontynuowania.
- Wdrażanie: prześlij wdrożenie do usługi Resource Manager i poczekaj na zakończenie.
- Test weryfikacyjny kompilacji: uruchom podstawowe testy po wdrożeniu względem niektórych ważnych zasobów, które zostały wdrożone. Te przeglądy są nazywane testami weryfikacyjnymi kompilacji 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ż:
- Sposób zatrzymywania procesu wdrażania potoków w przypadku nieoczekiwanego wystąpienia dowolnego z poprzednich etapów.
- Jak skonfigurować potok do wstrzymania do momentu ręcznego sprawdzenia, co się stało w poprzednim etapie.