Github Actions czy Jenkins? Czy warto korzystać z Github Actions?

Pisząc mniejszy czy większy projekt, aplikację czy bibliotekę, stajemy przed wyborem czy korzystać z automatyzacji procesów czy nie. Czy warto poświęcić czas na konfigurację automatycznych buildów, testów, releasów czy innych czynności?

Ja właśnie stanąłem przed takim wyborem. Dodatkowo przed jeszcze trudniejszym wyborem…

Github Actions czy Jenkins?

Spis treści

  1. Zacznijmy od początku
  2. Dlaczego Github Actions a nie Jenkins?
  3. Nie ma róży bez kolców – 2000 minut pracy miesięcznie
  4. Nie wszystko złoto co się świeci, czyli dlaczego prawie?
  5. Czego mi brakuje w Github Actions?
  6. Czy poleciłbym Github Actions?

Zacznijmy od początku

Do tej pory korzystałem z własnej instancji Jenkinsa. Dylemat pojawił się wtedy, gdy chciałem wykonywać release podczas push’u tagu. Musiałbym kombinować z refspec czy branch oraz jego wartościami jak refs/tags/* czy +refs/tags/*:refs/remotes/origin/tags/* . Średnio mi się podoba to rozwiązanie.

Spróbowałem Github Actions i…. chyba zbuduję z nim nie jednego builda…

Nie mam może wielkiego doświadczenia w tworzeniu pipeline w Jenkins – głównym celem było pobranie kodu z repozytorium, zbudowanie obrazu z odpowiednim tagiem, wrzucenie do własnego repozytorium z obrazami Dockera, a następnie przeprowadzić proces deploymentu (pobranie nowych obrazów, zaktualizowanie pliku .env i uruchomienie nowych kontenerów).

Zanim zacznę pisać wnioski na temat Github Actions chcę tylko powiedzieć, że dopiero poznaję to narzędzie. Podejść na wykorzystania akcji jest mnóstwo i nie ma jednego idealnego. Należy go dostosować do swoich potrzeb i możliwości

Dlaczego Github Actions a nie Jenkins?

Odpowiedzi jest kilka.

  1. Nowe narzędzie – chciałem poznać nowe rozwiązanie i wyjść ze strefy komfortu 🙂
  2. Kod jest na Githubie w rezultacie warto skorzystać z wbudowanego rozwiązania
  3. Łatwiejsze zarządzanie wyzwalaczami wydarzeń – eventy. Możemy zdefiniować kiedy akcja ma być wyzwolona (dziwnie brzmi polskie słowo trigger) – push, pull, release. Branch, tag… Bardzo dużo możliwości.
  4. Skorzystanie z gotowych elementów z marketplace. Korzystanie z pluginów w Jenkins wydaje mi się dość… toporne i starodawne. Korzystając z Sentry jako usługi do śledzenia błędów łatwo możemy skonfigurować release z Github Actions (konfiguracja Jenkinsa z Sentry – musimy wszystko obsłużyć ręcznie).

Nie ma róży bez kolców – 2000 minut pracy miesięcznie

Bezpłatnie możemy skorzystać z 2000 minut czasu pracy dla naszych akcji miesięcznie. Po wykorzystaniu tego czasu nasze akcje przestaną się uruchamiać.

Tutaj ważna wskazówka ode mnie. Warto ustawić timeout-minutes ponieważ nasza akcja może bardzo szybko zużyć cenne minuty jeśli coś pójdzie nie tak Wiem, bo miałem taki przypadek. Na szczęście okres rozliczeniowy szybko się skończył 🙂 Więcej informacji na temat rozliczania znajdziesz tu, tu i tu.

Domyślnie akcja posiada timeout po 360 minutach (6 godzin).

Nie wszystko złoto co się świeci, czyli dlaczego prawie?

Mimo, że zautomatyzowałem proces budowania aplikacji, budowania obrazu Dockerowego oraz wysłania go do mojego repozytorium, nadal proces deploymentu odbywa się poprzez Jenkinsa. Dlaczego?

  1. Nie do końca ufam połączeniu po SSH na serwer produkcyjny mimo, że uruchamiam na swoim runnerze (więcej w tym wpisie)
  2. Aktualny projekt nie jest jeszcze gotowy na Continuous delivery. Wolę ręcznie odpalić job na Jenkinsie 🙂 Być może wraz z większą ilością testów stabilność projektu będzie większa

Czego mi brakuje w Github Actions?

Na ten moment w Github Actions brakuje mi plików jako sekrety. Nie mogę wrzucić gotowego pliku .env i korzystać z niego w trakcie builda. Można dodać każdą zmienną osobno jako sekret a następnie „zbudować” sobie plik, ale mając kilkanaście zmiennych cóż… średnio wygodne rozwiązanie. Nie mówiąc już o aktualizacji (Jenkins potrafi trzymać pliki jako sekrety).

Nie możemy definiować zależności między akcjami. Jeśli 2 akcje wyzwalane są np na push to obie zostaną wykonane jednocześnie. Rozważmy przypadek, że na push tagu buduje nam się obraz z tagiem po push oraz tagiem latest.

Nie zawsze kolejność wykonania będzie zachowana, a trochę szkoda. Akcje mogłyby uruchomić się zgodnie z kolejnością commitów.

Na poniższym (bocznym) przykładzie obraz latest w wersji 0.9.7.9 zostanie nadpisany przez obraz 0.9.7.8. Szczęśliwie 0.9.7.10 zostało wykonane jako ostatnie.

Warto mieć to na uwadze.

Czy poleciłbym Github Actions?

Jeśli Twój projekt jest młody, repozytorium hostowane jest na Githubie, a proces budowania nie wymaga plików jako sekretów – wybierz Github Actions.
Jeśli nie ufasz Github lub Twój kod nie może stać na zewnętrznym Githubowym repozytorium – pozostaje Ci Jenkins.

PS. Testuj, baw się, nie zrażaj się próbami. Jak widzisz wciąż uczę się i próbuję nowych rozwiązań.

Github Actions czy Jenkins? Czy warto korzystać z Github Actions?
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
Zobacz wszystkie komentarze
Przewiń do góry