
Pomarańczowy lisek i rurociąg
W poprzednim artykule CI/CD? TO TAKIE NOWE AC/DC? przybliżone zostało pojęcie CI/CD praz przedstawiono zarówno jego wady jak i zalety. Z punktu widzenia osoby, która od kilku lat na codzień korzysta z tego rozwiązania mogę z ręką na sercu powiedzieć, że jest to coś z czego trudno zrezygnować.
Obecnie na rynku dostępnych jest wiele narzędzi odpowiadających za Ciągłą Integrację i Ciągłe Dostarczanie. Oczywiście dobór odpowiedniego narzędzia do projektu powinno być uzależnione od jego wymagań jak i budżetu jakim dysponujemy.
Narzędziem, wokół którego będą obracać się artykuły na tym blogu jest GitLab CI. Warto oczywiście poczytać o pozostałych rozwiązaniach na które możemy w przyszłości trafić, gdyż każdy projekt rządzi się innymi regułami, a co za tym idzie – technologiami. Łapcie link do ciekawego zestawienia najpopularniejszych rozwiązań CI/CD – 27 najlepszych obecnie dostępnych narzędzi CI / CD

Podstawowe pojęcia
W informatyce mało jest rzeczy niemożliwych – reszta jest zależna od czasu, który trzeba na nie poświęcić, budżetu i naszej wyobraźni. W projektach pojawiają się cuda automatyzacji, wykorzystujące wszystkie dobrodziejstwa dostarczone przez GitLab CI. Jadnak zanim sami zaczniemy tworzyć takie cuda – czy to dla siebie w domowym zaciszu, czy w ramach kolejnego zadania w Jira – musimy poznać podstawy.
Aby móc korzystać z dobrodziejstw GitLab CI/CD potrzebujesz:
- Projektu znajdującego się w repozytorium GitLab.
- Pliku .gitlab-ci.yml, w którym zostanie umieszczona konfiguracja CI/CD.
Bez pliku .gitlab-ci.yml nie zrobimy nic. Tak jak wcześniej wspomniałam to właśnie w nim przechowywana jest cała konfiguracja dla naszej aplikacji.
Można w nim zdefiniować:
- Skrypty, które chcemy wykonać.
- Sposób wykonywania skryptów – automatyczny lub manualny.
- Sposób wykonywania jobów – sekwencyjnie lub równolegle.
- Miejsce, gdzie zostanie zdeployowana aplikacja.
GitLab uruchamia pipeline (czyli po naszemu taki automatyczny potok) CI/CD dla projektu po zacommitowaniu zmian i wypchnięciu ich do zdalnego repozytorium.
To właśnie na pipelinie GitLab Runner uruchamia zdefiniowane przez nas skrypty, które są zgrupowane w Jobach. Natomiast wiele niezależnych Jobów może być pogrupowanych na coś takiego jak Stage, co pozwala uruchamianie ich w odpowiedniej kolejności.
Graficzne przestawienie całego procesu, które jest przejrzyste i przyjazne wizualnie dla developera umożliwia nie tylko szybsze dostarczanie nowych funkcjonalności na środowiska docelowe, ale i ułatwia identyfikacje błędów powstałych bezpośrednio po prowadzeniu zmian do repozytorium.
Skomplikowane? Gdy pierwszy raz to zobaczyłam to się przeraziłam. Dlatego, weźcie to wszystko na spokojnie i zacznijcie sami się tym bawić. W pracy będzie tylko gorzej… Tak, tam struktury plików konfiguracyjnych będą dużo bardziej skomplikowane niż to co zobaczycie tutaj.
Klawiatura w ruch!
Przygotowałam bardzo skromny projekt zawierający prostą konfigurację aby zaprezentować działanie GitLab CI. Projekt znajdziecie TUTAJ. Składa się dosłownie z kilku klas i testu, który jest uruchomiony przez job test. Zachęcam do przejrzenia i odtworzenia go u siebie. Pobawcie się konfiguracją, zobaczcie jak wszystko się zmienia po każdym commicie.
Konfiguracja zawarta w pliku .gitlab-ci.yml przedstawia się następująco:
- image: Pobranie najnowszego obrazu Maven w celu uruchomienia skryptów.
- stages: Zdefiniowanie dwóch – compile oraz test.
- Definicja jobów: compile, check mvn oraz test.
Zawartość pliku .gitlab-ci.yml:
image: maven:latest
stages:
- compile
- test
compile:
stage: compile
script:
- mvn compile
check mvn:
stage: compile
rules:
- when: manual
script:
- mvn -a
test:
stage: test
rules:
- when: on_success
script:
- mvn test -B
W dalszej części artykułu zobaczycie, jak tych kilka linijek kodu zmienia się w interfejsie graficznym w bardzo intuicyjne narzędzie.
GitLab CI – jak na to patrzeć?
W tym miejscu oprowadzę Was po interfejsie graficznym, żeby każdy z Was wiedział gdzie czego szukać w tym nowym świecie automatyzacji… albo przynajmniej gdzie zacząć.
Aby przeglądać wszystkie pipeliny musimy zerknąć na lewy panel GitLab, odnaleźć uroczą rakietę i wybrać opcję Pipelines.

Następnie przeniesieniu zostajemy do widoku prezentującego wszystkie pipeliny dla danego repozytorium.

Ten widok dostarcza wszelkich podstawowych informacji o danym pipelinie jak i pozwala podjąć z tego poziomu podstawowe akcje, takie jak:
- przejście do szczegółów pipelinu po kliknięciu w status lub pipeline id,
- przejście do commita powiązanego z pipelinem,
- po kliknięciu w dany Stage możliwe jest uruchomienie / ponowne uruchomienie wybranego Joba.

Przenieśmy się teraz do pełnego widoku naszego pipelinea! Jak już wiecie można to zrobić np poprzez wybranie pipeline id .

Jak widzicie mamy tu te same informacje co na poprzednim widoku i dodatkowo czytelniej zwizualizowane jest przedstawienie pipelinu z stageami i zawartymi w nich jobami.
Dlatego od razu widać tu wszystko to, co zawarte zostało w pliku .gitlab-ci.yml.
- Stage Compile: job compile – uruchomił się automatycznie po wypchnięciu zmian do repozytorium.
- Stage Compile: job check mvn – czeka na uruchomienie manualne.
- Stage Test: job test – uruchomi się automatycznie po tym jak wszystkie joby w stage Compile wykonają się z sukcesem.
Jak widzicie interfejs graficzny GitLab CI jest przejrzysty i intuicyjny. Klikajcie, bawcie się… i psujcie. Lepiej coś popsuć we własnym repozytorium i to naprawić niż popsuć w pracy i wołać kolegów.
Czy to wszystko jest darmowe?
Jak się pewnie domyślacie niestety nie. Możliwość wykorzystywania CI/CD jest ograniczona… czasem. Dla każdego konta jest dostępnych 400 darmowych minut wykonywania pipelinów. Później, tak jak telefon na kartę, musimy nasze konto doładować dodatkowymi minutami. Musimy również pamiętać o tym, że jest to liczone wszystkich projektów razem a nie dla każdego z osobna.
Informacje o wykorzystanych minutkach możecie znaleźć pod ścieżką Avatar -> Preferences -> Usage Quotas.

Podsumowanie
Z założenia ten blog miał krok po kroku opisywać w przystępny sposób tematy techniczne osobom, które są totalnie zielone. Dlatego tym razem, dowiedzieliście się podstaw o jednym z narzędzi, które umożliwia wprowadzenie CI/CD. Sama od kilku lat na codzień korzystam z GitLab CI i jestem szczęśliwa, że trafiłam do projektu, w którym zostało ono wdrożone.
GitLab CI jest jest tym czego nowoczesne zespoły tworzące oprogramowanie potrzebują do sprawnego dostarczania nowych funkcjonalności, a co za tym idzie – wartości biznesowej. Automatyzacja procesów budowania, testowania i dostarczania aplikacji na środowiska docelowe oszczędza programistom wiele czasu i niepotrzebnego stresu.
Dlatego też pobawcie się nim u siebie. Załóżcie konto, stwórzcie prosty projekt a następnie przygotujcie dla niego pierwszy, samodzielnie stworzony plik .gitlab-ci.yml. Zróbcie to szczególnie jeśli jeszcze nigdy nie mieliście styczności z GitLab CI. Będzie to dla Was mniejszą niewiadomą gdy traficie do projektu, w którym jest to wdrożone.
Twórzcie. Testujcie. Psujcie. Naprawiajcie. Bawcie się dobrze.