Aleksander Radovan
Autor:
Aleksander Radovan

Voditelj Java tima

Continuous Integration s Gitom i Jenkinsom – je li isplativo?

Zašto je potrebna kontinuirana integracija?

Na projektima s više developera jedina opcija za omogućavanje paralelnog rada je korištenje centralnog repozitorija programskog koda s kojim će se programeri sinkronizirati na dnevnoj bazi. Svaka promjena koja se dodaje na centralni repozitorij potencijalno može narušiti stabilnost aplikacije i time onemogućiti ostalim developerima u timu da nesmetano razvijaju svoje funkcionalnosti. Sprečavanje takvih situacija ili barem smanjivanje vjerojatnosti da se to dogodi može cijelom timu uštediti znatnu količinu vremena ako se bugovi detektiraju u fazi razvoja, a ne u fazi testiranja aplikacije kad je ona deployana na testne poslužitelje.

Continuous Integration (CI) se svodi na svakodnevnu praksu da developeri automatizirano integriraju svoje promjene na centralni repozitorij, pri čemu se svi problemi mogu detektirati nakon commita promjena na centralni repozitorij, a ne tek kad se aplikacija deploya na aplikacijski poslužitelj. Provjera ispravnosti novih promjena provodi se pomoću unitintegration testova koje developeri moraju pisati paralelno s razvijanjem funkcionalnosti aplikacije, što iziskuje discipliniranost developera. Testovi se obavljaju nad „in-memory“ bazom podataka koja se nalazi u memoriji samo u fazi izvođenja testova, a nakon njihovog završetka briše se iz memorije. Nova verzija (build) aplikacije se isporučuje samo u slučaju kad svi testovi „prolaze“, a u suprotnom se obavještavaju svi članovi tima o razlogu „pada“ nekog od testova što ujedno i onemogućava kreiranje nove verzije aplikacije.

U praksi se pokazalo ključnim da svaki developer prije nego što commita svoje promjene na centralni repozitorij, lokalno pokrene sve testove i time dobiva povratnu informaciju hoće li njegove promjene „srušiti build“. Ako developer zaboravi lokalno pokrenuti testove i svejedno commita promjene na centralni repozitorij, integration server poput Jenkinsa automatski pokreće sve testove čim detektira ulazne promjene na centralnom repozitoriju te obavještava sve developere u timu ako je build postao nestabilan ili je build proces završio pogreškom. U praksi se češće događa da buildovi postaju nestabilni ako developer ne commita sve promjene iz svog workspacea koje su sastavni dio funkcionalnosti pa se na centralnom repozitoriju programski kod ne kompajlira.

Korištenjem CI-a se štedi vrijeme za pronalazak i ispravak bugova koji nastaju integriranjem promjena više developera na projektu, ali ne sprečava njihov nastanak. Ako se dogodi problem, svaki developer u timu može dobiti sve informacije o tome kako ispraviti problem i tako opet build vratiti u stabilno stanje.

Instaliranje i konfiguriranje Jenkinsa

Jenkins je moguće preuzeti u WAR obliku i pokreće se iz komandne linije naredbom „java –jar jenkins.war“. U slučaju da je potrebno kod pokretanja Jenkinsa definirati proxy podatke i koristiti specifični port (a ne defaultni 8080), potrebno je izvršiti naredbu „java -Dhttp.proxyHost=192.168.101.102 -Dhttp.proxyPort=8080 -jar jenkins.war --httpPort=8085“. Te postavke je također moguće mijenjati unutar XML datoteka koje se nalaze u „JENKINS_HOME“ mapi, koja može biti nešto poput „C:\Users\my_user\.jenkins“.

Konfiguriranje proxy servera, portova na kojem će se aplikacija izvoditi i slično moguće je konfigurirati i unutar same administracijske konzole Jenkinsa korištenjem opcije „Manage Jenkins“.

Na ekranu koji se pojavljuje korištenjem opcije „Configure System“ moguće je definirati razne globalne postavke kao što su environment varijable, SSH postavke, SMTP poslužitelj i slično.

Svaka od tih postavki može se jednostavno konfigurirati tako da se najprije instalira plugin koji omogućava dodavanje nove funkcionalnosti te nakon toga definiraju parametri za tu funkcionalnost. Na primjer, ako je potrebno instalirati podršku za Git repozitorij, nakon instalirana plugina potrebno je definirati lokaciju gdje je Git instaliran na računalo gdje se izvodi Jenkins.

 

Najveća prednost Jenkinsa je upravo ta mogućnost instalacije najrazličitijih pluginova s kojima ga je moguće prilagoditi da se spaja na centralne repozitorije kao što je Git, izvođenje naredbi raznih frameworka kao što je Grails, provjeru kvalitete programskog koda različitih jezika kao što su Java, Groovy i JavaScript, pokretanje zadataka za provjeru kvalitete programskog koda i kreiranje izvještaja o dobivenim rezultatima, pokretanje command line naredbi itd. Prije instaliranja pluginova je potrebno definirati postavke proxy servera (ako je potrebno) korištenjem opcije „Manage Jenkins->Manage Plugins“ i odabrati „Advanced“ tab te na njemu definirati potrebne detalje:

Konfiguracija projekta u Jenkinsu

Jenkins funkcionira na način da se u njemu kreiraju projekti za repozitorije nad kojima je potrebno obavljati operacije continuous integrationa. Odabirom opcije „New Item“ na osnovnom izborniku moguće je birati vrstu projekta koji je potrebno kreirati:

Nakon toga se prikazuje ekran na kojem je moguće definirati detalje vezane uz konfiguraciju samog projekta, lokacija repozitorija programskog koda i sl.:

Moguće je konfigurirati i način na osnovu kojeg se pokreće automatski build. Na primjer, ako je potrebno svakih pet minuta provjeriti je li došlo do neke promjene na centralnom repozitoriju i prema tome pokrenuti novi build (oznakom H/5 * * * *).

U slučaju da je potrebno definirati specifične varijable okoline kojima se omogućava korištenje više memorije samom build procesu, to je moguće implementirati korištenje plugina „EnvInject“ nakon čega se pojavljuju opcije za definiranje „JAVA_OPTS“ varijable okoline (povećanjem memorije koju smiju koristiti buildovi može znatnije skratiti vrijeme potrebno za sam build):

Build proces može se sastojati od proizvoljnog broja koraka koji mogu biti vezani uz izvršavanje batch commandi kao što je „bower install“ ili slično:

U slučaju potrebe pokretanja Grails naredbi potrebno je kreirati korake koji koriste karakteristične konfiguracijske detalje:

Na kraju je još moguće dodati i završne (Post-build Actions) korake koji mogu biti vezani uz arhiviranje resursa, objavljivanje izvještaja i dokumentacije ili slanje mailova svim članovima projekta da odmah budu obaviješteni o tome je li build uspješno prošao ili ne:

Korištenjem Continuous integration alata kao što je Jenkins sam proces razvoja moguće je unaprijediti tako da se puno ponavljajućih zadataka kao što je buildanje aplikacije, deployanje aplikacije na aplikacijske servere, pokretanje batch skripti, izvršavanje naredbi vezanih uz programski okvir kao što je Grails ili pokretanje provjere kvalitete programskog koda pomoću sustava Sonar. Veliki broj dostupnih pluginova kao i kontinuirano usavršavanje funkcionalnosti samog Jenkinsa osiguravaju maksimalnu kompatibilnost sa svim aktualnim tehnologijama, alatima i programskim jezicima i frameworkovima, što ga čini vrlo popularnim među programerima. Velika popularnost Jenkinsa rezultirala je i organiziranjem konferencija pod nazivom "Jenkins User Conference" po velikim gradovima diljem svijeta, a open source licenca osigurava mu svakodnevnu ekspanziju broja korisnika i samim time kvalitetniti i stabilniji rad sustava. 

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta