Dziś się nie będziemy rozmawiać, czym jest YAML. Jak wygląda, ani gdzie go trzymać. Skupimy się na temacie ważniejszym. Konkretnie, dlaczego YAML w CI/CD jest koniecznością oraz dlaczego warto iść w stronę Pipeline as Code, zamiast konfiguracji w GUI.
1. Pull requesty
Ten element zagościł już na stale w procesie wytwarzania oprogramowania. Dzięki niemu, bez problemu, przeprowadzamy asynchroniczne Code Review oraz prowadzimy dyskusje o konkretnych zmianach.
Skoro jest tak przydatny i przyjemny, warto go użyć do konfiguracji CI/CD, a zabieramy sobie tę możliwość, korzystając tylko z GUI.
Korzystając z Pipeline as Code, pozwalasz sobie na zatwierdzanie zmian konfiguracji oraz, co lepsze, na możliwość prowadzenia dyskusji, która zostanie zarchiwizowana.
2. Test różnych konfiguracji
Jak testować zmiany w Pipeline, konfigurując go w GUI? Dość trudno. Gdy modyfikujesz proces CI/CD i nie jesteś pewien, czy to zadziała. Możesz być w jednej z dwóch sytuacji.
Nowy projekt
Dodajesz nowy projekt i chcesz, aby od razu się budował. Mając konfigurację CI w GUI, jest to problematyczne, ponieważ pojawia się pytanie, kiedy dodać budowanie nowego projektu? Przed mergem? Po merge? To wtedy przez chwilę mamy niestabilne buildy lub musisz tworzyć kopię konfiguracji, by potem przenosić ją ręcznie. Barbarzyństwo!
Mając Pipeline as Code, sytuacja jest o niebo prostsza. Na branczu, gdzie dodajesz nowy projekt, modyfikujesz plik YAML. Dzięki temu sprawdzisz w bezpieczny sposób czy to działa, a ponadto zmiana konfiguracji zostaje wciągnięta wraz z merdżem. Piękna sprawa!
Modyfikacje Pipeline
Chcesz dodać automatyczną analizę pokrycia kodu testami? Potrzebujesz przyspieszyć cały proces, np. dodając Cache lub wprowadzając do niego zaawansowane mechanizmy. Jednak wcześniej, chcesz się upewnić, że wszystko jest na swoim miejscu, a główny build był niestabilny.
W takiej sytuacji tworzysz brancza. Na nowej gałęzi wprowadzasz zmiany w YAML. Analizujesz, testujesz, sprawdzasz, czy jest wszystko ok. Jeżeli jesteś zadowolony z rezultatu to mergujesz do mastera i wszystko cały czas działa.
3. Łatwa i przyjemna analiza historii
Próbowałeś kiedyś przeanalizować historię zmian wprowadzanych poprzez interfejs użytkownika? Obojętnie, czy jest to serwer CI, czy cokolwiek innego. To zawsze jest droga przez mękę. Olbrzymie pliki XML, czy te bardziej nowoczesne, JSON. Poza ich rozmiarem, zmiany wyglądają na losowe, bo przecież mają służyć maszynie, nie ludziom.
Zupełnym tego przeciwieństwem, jest analiza historii, gdy posiadasz konfigurację CI w pliku YAML. W takiej sytuacji używasz całej potęgi gita i przeglądasz ładne, proste i czytelne pliki tekstowe.
4. Możliwe i łatwe merge
Zmiany wprowadzone w GUI nie są wersjonowane w GIT. Co prawda, niektóre serwery CI mają własny sposób trzymania historii, ale jak przeczytałeś w powyższym punkcie, nie są one przystępne dla człowieka. Nawet jeżeli będziesz chciał je połączyć, będzie to uciążliwe, a zazwyczaj niemożliwe. Zupełnie odwrotnie niż w przypadku PaC.
Ponieważ Pipeline as Code jest trzymany w plikach tekstowych, możesz, bez najmniejszego problemu, wprowadzać zmiany niezależnie, na różnych branczach.
Ponadto, jeżeli dwie osoby będą aktualizować Pipeline, to masz później możliwość połączania tych zmian. A merge nie powinien być skomplikowany, gdyż operujesz na plikach tekstowych, czyli jak na kodzie źródłowym.
5. Odpowiedzialność zostaje w zespole
Często odpowiedzialność za konfigurację CI/CD jest wydelegowana gdzieś na zewnątrz, lub do specjalnego członka zespołu, tak zwanego DevOpsa. Jest to rozwiązanie ekstremalnie niewydajnie, ponieważ pozbawiamy zespołu deweloperskiego autonomiczności i odpowiedzialności.
Jeżeli chcesz, aby zespół był samowystarczalny i wydajny to powinien zarządzać procesem budowania i dostarczania aplikacji samodzielnie. Wybierając Pipeline as Code, jest to naturalne, ponieważ konfiguracja pipeline leży w repozytorium i programiści będą czuć większą odpowiedzialność za wytwarzanie i dostarczanie produktu.
6. Łatwiejsze użycie w nowych projektach
Idąc drogą Pipeline as Code, mamy plik konfiguracyjny. Ten plik możemy użyć jako zaczątek konfiguracji CI w nowym projekcie. Jest to dużo prostsze i wygodniejsze niż kopiowanie ustawień w GUI. W związku z tym każdy kolejny projekt będzie startował szybciej, ponieważ część konfiguracji będzie już gotowa.
7. Przyszłość i nowoczesność
Biorąc pod uwagę powyższe zalety oraz obserwując trendy na rynku, stwierdzam, że PaC jest przyszłością. Wszystkie nowe serwery CI wspierają podejście Pipeline as Code. Natomiast stare implementują taką opcję konfiguracji.
Przykładami mogą być Azure DevOps oraz GitHub Actions, o których możesz przeczytać na tym blogu.
Przekonałem Cię do Pipeline as Code?
Czy Ty podążasz ścieżką PaC, czy opierasz swój CI/CD na GUI?
A może chcesz coś dodać lub podyskutować?
Daj znać w komentarzu lub zapisz się na newsletter.
Bądźmy w kontakcie.
2 Komentarze
Piotr · 5 września, 2020 o 19:15
Mam build pipeline w yaml, a release pipeline w UI. System składa się z wielu komponentów i mam środowiska na które deployment musi być zatwierdzony przez kogoś z listy osób. Z UI fajnie się to śledzi. Jak wygląda to gdy release pipeline jest w yaml? Jak śledzi się kto, gdzie kiedy i co zdeployował? Albo że jakiś deployment czeka na zatwierdzenie?
Jerzy Wickowski · 8 września, 2020 o 19:24
Cześć @Piotr,
Bardzo przyjemny pomysł na kolejny post. Jak poukładam to ładnie to dam znać.
Jednak chciałbym się upewnić na starcie, w jakim narzędziu konfigurujesz CI/CD? Azure Pipelines, czy coś innego?