Jenkins to otwartoźródłowy serwer automatyzacji napisany w Javie, który spina cały cykl dostarczania oprogramowania w jeden powtarzalny proces. Najczęściej używasz go do budowania potoków CI/CD (Continuous Integration / Continuous Delivery), czyli do tego, żeby kod po każdym commicie sam się zbudował, przeszedł testy i — jeśli wszystko gra — trafił na serwer. Projekt narodził się jako Hudson w Sun Microsystems, a po sporze z Oracle został w 2011 roku rozwidlony (fork) i dalej żyje jako Jenkins pod skrzydłami fundacji CD Foundation.
Jak to działa
Sercem Jenkinsa jest pipeline — przepis na to, co ma się stać z Twoim kodem. Definiujesz go w pliku Jenkinsfile trzymanym w repozytorium (czyli „pipeline as code”, wersjonowany razem z aplikacją). Jenkins nasłuchuje na zmiany — przez webhook z GitHuba/GitLaba albo cyklicznie odpytując repo — i kiedy pojawi się nowy commit, odpala kolejne etapy: pobranie kodu, kompilacja, testy, pakowanie, deploy.
Architektura jest typu controller–agent (kiedyś nazywana master–slave). Controller zarządza zadaniami i interfejsem, a faktyczną robotę wykonują agenci — osobne maszyny, kontenery albo węzły, które możesz mnożyć, gdy buildów jest dużo. Resztę funkcji dokłada gigantyczny ekosystem wtyczek (ponad 1800), od integracji z Dockerem po powiadomienia na Slacku.
Przykład z praktyki
Prosty Jenkinsfile w składni deklaratywnej wygląda tak:
pipeline { agent any }— uruchom na dowolnym dostępnym agencie,stage('Build') { steps { sh 'mvn clean package' } }— zbuduj projekt Mavenem,stage('Test') { steps { sh 'mvn test' } }— odpal testy,stage('Deploy') { steps { sh './deploy.sh' } }— wdróż.
Po pushu na branch Jenkins przechodzi przez te etapy po kolei i przy pierwszym czerwonym teście zatrzymuje pipeline, zanim zepsuty kod dotrze na produkcję.
Na co uważać
Najczęstszy mit to „Jenkins jest przestarzały”. Owszem, nowsze rozwiązania jak GitHub Actions czy GitLab CI są wygodniejsze na start, ale Jenkins wciąż króluje tam, gdzie potrzebna jest pełna kontrola i hosting on-premise. Realne pułapki: plugin hell (wtyczki potrafią się gryźć i psuć przy aktualizacji), trzymanie pipeline’ów w GUI zamiast w Jenkinsfile oraz dziurawe bezpieczeństwo — instancja wystawiona do internetu bez uwierzytelnienia to klasyczny cel ataku. Trzymaj konfigurację w kodzie i regularnie aktualizuj.
Pojęcia powiązane
CI/CD, pipeline, Jenkinsfile, Groovy, Docker, Git, build automation, DevOps, GitHub Actions, GitLab CI.