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:

1. image: Pobranie najnowszego obrazu Maven w celu uruchomienia skryptów.
2. stages: Zdefiniowanie dwóch – compile oraz test.
3. 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.