Strona Główna / Blog

Już jest! Multi-stage YAML Pipelines w Azure DevOps

Krystian Kucharski

Krystian Kucharski

Azure Architect w Chmurowisku. Odpowiada za realizację projektów dookoła wdrożeń i migracji rozwiązań do chmury Microsoft Azure. Specjalizuje się w rozwiązaniach PaaS, konteneryzacji i procesach CI/CD.

Nareszcie! Ile można czekać?!

Tak całkiem niedawno zareagowała społeczność użytkowników Azure DevOps na zapowiedź obsługi multi-stage YAML Pipelines w Azure DevOps.

Co prawda obsługa wieloetapowych potoków (pipeline’ów) YAML w chwili publikacji tego artykułu jest nadal w fazie Preview, ale wszystko wskazuje na to, że jej rozwój idzie w dobrym kierunku.

To znaczy w jakim?

Zachęcam do lektury artykułu😉

Everything-as-Code

Azure zawsze stara się wychodzić naprzeciw potrzebom klientów. Aby sprostać ich oczekiwaniom, jakiś czas temu firma rozszerzyła możliwości Azure DevOps o obsługę multi-stage YAML Pipelines, pozwalającą na budowanie wielu etapów w pojedynczej definicji potoku YAML.

Do tej pory mogliśmy używać definicji YAML do budowania procesów ciągłej integracji (Continuous Integration). Teraz możemy w niej także ująć procesy ciągłego wdrażania (Continuous Deployment).

Oznacza to, że wszystkie etapy budowania, testowania oraz wdrażania kodu możemy zamknąć w jednej definicji YAML:

Przejdźmy dalej, aby przekonać się, jak ten mechanizm sprawdza się w praktyce.

Jak uruchomić multi-stage YAML Pipelines?

Aby przetestować funkcję, logujemy się do Azure DevOps i odnajdujemy w prawym górnym rogu konsoli ikonę z naszym użytkownikiem. Następnie klikamy w pozycję Preview features.

Tutaj upewniamy się, że opcja Multi-stage pipelines jest włączona.

Teraz możemy przejść do sekcji Pipelines, gdzie w lewym menu wybieramy pozycję Pipelines, po czym klikamy [Create Pipeline], aby przejść do stworzenia nowego potoku.

Jako źródło kodu dla naszego potoku wybieramy Azure Repos Git.

Następnie wybieramy dowolne repozytorium, na którym ma zostać zapisana definicja potoku.

W kolejnym kroku klikamy Starter pipeline, aby rozpocząć tworzenie definicji potoku.

Aby zbytnio się nie męczyć, wcześniej przygotowałem już definicję potoku. Wystarczy wkleić ją do edytora YAML.

Definicja ta jest symulacją procesu potoku i składa się z czterech etapów (bloków stage): budowania kodu, testów, wdrożenia na środowisko deweloperskie oraz wdrożenia na środowisko odpowiedzialne za testy:

Po poprawnym wklejeniu definicji do edytora YAML klikamy [Save and run], aby uruchomić nasz potok:

W odświeżonym graficznym interfejsie możemy zobaczyć jego status:

Kliknijmy teraz w pierwszy etap potoku, Build Applications:

Zobaczymy wówczas nową, odświeżoną wersję interfejsu logowania:

Jak widać, cały proces został uruchomiony sekwencyjnie, od momentu budowania kodu na etapie Build, poprzez testowanie kodu na etapie Test, aż do wdrożeń na środowiska oznaczone kolejno jako Develop oraz QA.

Wieloetapowe potoki YAML: dodawanie warunków

Multi-stage YAML Pipelines umożliwiają dodawanie warunków w blokach etapów, które będą decydowały o wykonywaniu bloku. Zobaczmy, jak one działają.

Najpierw musimy wejść w widok wcześniej uruchomionego potoku. W prawym górnym rogu klikamy ikonę z trzema kropkami, a następnie wybieramy pozycję Edit pipeline:

Następnie wyszukujemy blok o nazwie QA i dodajemy w nim następujący parametr:

W efekcie definicja etapu QA powinna wyglądać następująco:

Oznacza to, że ten etap zostanie wykonany, jeśli gałęzią w źródłowym repozytorium kodu, z którego będzie budowana aplikacja na etapie Build, będzie gałąź o nazwie qa.

Po wprowadzeniu zmian całość definicji potoku powinna wyglądać następująco:

Zapisujemy stan definicji, klikając Save, a następnie klikamy Run, aby uruchomić proces.

W efekcie powinniśmy otrzymać następujący rezultat:

Jak widać, blok QA nie został wykonany, zgodnie z wytycznymi.

Status Skipped świadczy o pominięciu tego etapu, ponieważ źródłową gałęzią jest gałąź master, a nie qa.

Podsumowując, wszystko poszło zgodnie z planem.

Mutli-stage YAML Pipelines: zależności

Zależności pozwalają na budowanie potoków, w których proces zawiera układ zależnych od siebie etapów.

Aby nieco przybliżyć tę funkcję, rozpoczniemy od edycji potoku.

Na początek edytujemy w definicji potoku ostatni blok o nazwie QA zgodnie z poniższą konfiguracją:

Zauważmy, że pojawił nam się nowy znacznik:

Powyższy zapis znacznika dependsOn mówi o tym, że blok QA1 jest zależny od bloku Develop i nie zostanie uruchomiony, dopóki blok Develop nie zostanie wykonany.

W następnym kroku dodamy do definicji kolejne dwa bloki z etapami:

Po wprowadzeniu zmian całość definicji potoku powinna wyglądać następująco:

Na koniec zapisujemy zmiany w definicji, klikając Save, a następnie klikamy Run, aby uruchomić proces.

Nasz potok powinien teraz wyglądać następująco:

Jak widzimy, bloki etapów QA1 oraz QA2 są zależne od bloku Develop, natomiast ostatni blok Pre-Prod, wykonujący wdrożenie na środowisku przedprodukcyjnym, jest zależny od bloków QA1 oraz QA2.

Dokonajmy teraz drobnej modyfikacji w bloku QA2, symulując niepowodzenie w wykonaniu potoku:

Po wprowadzeniu zmian całość definicji potoku powinna wyglądać następująco:

Sprawdźmy, co się teraz stanie. Klikamy Save i Run, aby zapisać i uruchomić proces.

Jako wynik powinniśmy zobaczyć następujący rezultat:

W tym przypadku mechanizm ponownie zadziałał prawidłowo – blok Pre-Prod nie został uruchomiony, ponieważ jeden z etapów, od którego jest zależny, a mianowicie blok QA2, nie został ukończony poprawnie.

Podsumowanie

Azure DevOps nieustannie wzbogaca się o nowe możliwości. Obsługa multi-stage YAML Pipeline jest jedną z nich. Integracja procesów CI i CD w jednym potoku to krok w dobrym kierunku, który wyraźnie sugeruje, że implementacja Everything-as-Code w Azure DevOps jest już całkiem blisko.

Już wkrótce otwieramy nowe kursy

Zostań specjalistą chmury publicznej

Dołącz do listy mailingowej!

Dołącz do naszego newslettera

Staramy się wysyłać tylko wartościowe informacje, np. co miesiąc dostaniesz spis najważniejszych nowości z chmur Azure, AWS i GCP, z krótkimi opisami i linkami.