Jenkins - weteran automatyzacji, który wciąż daje radę

Jenkins to jedno z tych narzędzi, które w świecie DevOps są jak dobrze znany stary znajomy. Open-source'owy, rozpoznawalny i od lat obecny w projektach na całym świecie. Dla wielu zespołów to właśnie on stanowi fundament procesów CI/CD - czyli ciągłej integracji i dostarczania (czy też wdrażania) oprogramowania. Elastyczny do bólu, z tysiącami dostępnych wtyczek, daje się dopasować niemal do każdego projektu i stacku technologicznego. Wciąż trzyma się mocno, szczególnie w dużych organizacjach, choć niektórzy zaczynają przenosić się na nowsze rozwiązania, jak GitLab CI/CD czy GitHub Actions. A jak to bywa z migracjami - nie obywa się bez wyzwań, i to nie tylko technicznych, ale też prawnych.

Co to w ogóle jest ten Jenkins?

W największym skrócie: Jenkins to centrum zarządzania automatyzacją. Śledzi zmiany w repozytoriach (np. Git) i na ich podstawie odpala z góry zdefiniowane procesy - tzw. pipeline’y.

Do czego najczęściej się go używa?

• Automatyczne budowanie i kompilacja kodu - np. po każdym git push czy wystawieniu pull requesta.
• Testy jednostkowe i integracyjne - żeby błędy wychwytywać jak najwcześniej i oszczedzać czas w trakcie wdrożeń produkcyjnych.
• Zarządzanie infrastrukturą jako kodem (IaC) - np. do stawiania zasobów w chmurze. Sam kiedyś używałem Jenkinsa do wdrażania infrastruktury w AWS przy pomocy Terraforma oraz do zarządzania wdrożeniami na serwerach przy pomocy Ansible.
• Automatyzacja wdrożeń aplikacji - z użyciem narzędzi typu Ansible do ogarniania serwerów linuksowych.

Brzmi pięknie? No właśnie - ale nie zawsze tak jest

Choć Jenkins daje naprawdę sporo możliwości, to nie wszystko w nim jest różowe. Najczęściej narzekania dotyczą... aktualizacji. Sam Jenkins i jego wtyczki potrafią zmieniać się dość dynamicznie, a nowe wersje nierzadko nie dogadują się z istniejącymi pipeline’ami. Bywa, że coś nagle przestaje działać - i powrót do poprzedniego stanu to nie zawsze bułka z masłem.

Tutaj z pomocą przychodzi uruchamianie Jenkinsa w kontenerze Dockera. Taki patent ma sporo zalet:

1. Cała konfiguracja zapisana jest jako kod (Dockerfile), więc łatwo ją odtworzyć.
2. Aktualizacje można spokojnie testować lokalnie - zanim trafią na produkcję.
3. A jak coś pójdzie nie tak, to przywracasz starszą wersję obrazu oraz kopie danych - szybko i bezboleśnie.

Druga często spotykana przeszkoda to zarządzanie użytkownikami i uprawnieniami. W wersji podstawowej Jenkins ma tu dość ograniczone możliwości - żeby je rozbudować, trzeba sięgnąć po kolejne wtyczki.

A co, jeśli Jenkins to nie Twoja bajka?

Choć Jenkins to prawdziwy dinozaur automatyzacji, to nie brakuje nowszych, często bardziej przyjaznych alternatyw:

• GitLab CI/CD - w pełni zintegrowany z GitLabem, konfigurowany w pliku .gitlab-ci.yml.
• GitHub Actions - rozwiązanie natywne dla GitHuba, które szybko zyskuje fanów dzięki prostocie i bogatemu marketplace’owi gotowych akcji.
• CircleCI, Travis CI, AWS CodePipeline - inne popularne opcje, często dostępne w modelu SaaS.

Co wybrać? To już zależy od wielu rzeczy: wielkości projektu, potrzeby kontroli nad środowiskiem (Jenkins jest self-hosted), preferencji zespołu... No i tego, czy chcesz spędzać wieczory na walce z konfiguracją, czy jednak wolisz coś, co działa „out of the box”.