Continuous Integration w oparciu o Jenkins – cześć 1

Ciągła integracja (z ang. Continuous Integration) pozwala rozwiązać problem budowania, testowania oraz integracji kodu. Nie jest to jednak rozwiązanie które stanowi remedium na wszystkie problemy, ale znacząco eliminuje ryzyko występowania błędów. Każdy programista w zespole ma dostęp do repozytorium kodu źródłowego np. do gita. Zewnętrzne oprogramowanie np. Jenkins po tym jak zostanie wykryta zmiana w kodzie źródłowym automatycznie buduje aplikację i uruchamia testy. Jeśli testy zakończą się powodzeniem system ciągłej integracji informuje o tym. Jeśli natomiast testy zakończą się niepowodzeniem, cały zespół zostanie o tym niezwłocznie poinformowany np. za pomocą maila czy wiadomości na komunikatorze firmowym np. Slack. Dlaczego to zagadnienie jest tak ważne, otóż bez szybkiego dostarczenia produktu do klienta nie jesteśmy w stanie uzyskać szybkiej informacji zwrotnej która jest bardzo istotna z punktu widzenia biznesowego. Ciągła integracja przyspiesza rozwój produktu, eliminuje potencjalne błędy oraz w konsekwencji pozwala na uzyskanie szybkiego feedbacku od klienta na ten temat produktu. W artykule tym zainstalujemy Jenkinsa jako aplikację webową *.war, skonfigurujemy wtyczkę dla Mavena oraz wykonamy zadania budowania aplikacji kiedy dojdą zmiany w kodzie źródłowym (wykonane zostanie polecenie push):

Pobieramy aplikację Jenkinsa – plik jenkins.war:

http://mirrors.jenkins.io/war-stable/latest/

Jenkins może być uruchomiony na zewnętrznym serwerze np. Tomcat kopiując plik *.war lub może być uruchomiony samodzielnie ze względu na wbudowany serwer – Winstone (Jetty) za pomocą komendy:

java -jar jenkins.war

Running from: C:\Users\EMAWARY\Downloads\jenkins.war
webroot: $user.home/.jenkins
lip 29, 2019 11:51:20 AM org.eclipse.jetty.util.log.Log initialized
INFO: Logging initialized @801ms to org.eclipse.jetty.util.log.JavaUtilLog
lip 29, 2019 11:51:20 AM winstone.Logger logInternal
INFO: Beginning extraction from war file
...

Jenkins wygeneruje losowe hasło które służy do odblokowania Jenkinsa:

Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:
 
cba7e42acb414a3eb9fd4a0d2ae6504d
 
This may also be found at: .\jenkins\secrets\initialAdminPassword

W kolejnym kroku instalujemy wymagane wtyczki – ten proces trochę trwa:

W kolejnym kroku konfigurujemy konto administratora:

Po konfiguracji przechodzimy po adres:

http://localhost:8080/

Jenkins zainstalowany, przechodzimy do konfigurowania oprogramowania. W części pierwszej konfiguracja dotyczyć będzie lokalnego repozytorium zlokalizowanego na dysku. W części drugiej zajmiemy się natomiast konfiguracją Jenkinsa i GitHuba. Po zalogowaniu do konsoli Jenkinsa tworzymy nowy projekt:

Instalujemy wtyczkę Git Changelog:

W konfiguracji projektu dodajemy adres repozytorium oraz zaznaczamy – „pobierz z repozytorium kodu„. Harmonogram pozostawiamy bez zmian i nie przejmujemy się komentarzem: „No schedules so will only run due to SCM changes if triggered by a post-commit hook”. Przyznam, że nie jest to zbyt intuicyjne…

Wchodzimy na adres:

http://localhost:8080/git/notifyCommit?url=C:/users/mwarycha/downloads/sonar/jenkins/

następnie z poziomu Jenkinsa przeglądamy – „Git Rejestr pobrania z repozytorium kodu”

Gdy wywołamy adres:

http://localhost:8080/git/notifyCommit?url=c:/Users/mwarycha/Downloads/jenkins

i zajdą zmiany w repozytorium otrzymamy wynik jak na poniższym screenie. Dodatkowo zauważyć można, że zadanie budowania aplikacji automatycznie zostało uruchomione.

Teraz należy w momencie wykonania instrukcji push wywołać powyższy adres, w tym celu dodajmy do GITa odpowiedniego hooka, w katalogu ./git/hooks tworzymy zatem plik – pre-push (bez rozszerzenia) z zawartością:

#!/bin/sh
curl http://localhost:8080/git/notifyCommit?url=c:/Users/mwarycha/Downloads/jenkins

polecenie git push uruchomi Hooka:

Co w konsekwencji doprowadzi to uruchomienia zadania w Jenkinsie: