Šta je kontinualna integracija i zašto je primenjivati?

Svet u kome živimo se razvija neverovatnom brzinom što vodi do pojavljivanja sve sofisticarnijih tehnologija u sve kraćim vremenskim intervalima. Tendencija brzih isporuka, kratkih ciklusa i lakih pivota su izuzetno popularne pojave u svetu razvoja softvera. Značaj brzine izlaska na tržište i ispravljanja grešaka je naročito izražen u startup svetu. Sa nama ponovo, u ulozi autora COO Devana Technologies Ivan Bjelajac. 

Problem brzog prelaska softvera iz faze ideje do korisnika je najozbiljniji problem sa kojim se programeri danas suočavaju.

Agilni razvoj pruža priiku za bolju procenu napretka duž razvojnog ciklusa, a daje i priliku za dobijanje pravovremenog feedbacka od strane korisnika, koji lako može dovesti do promene pravca. Ovo se postiže redovnim kadencama posla, poznatim pod nazivima sprint ili iteracija, nakon kojih timovi moraju da prezentuju potencijalno isporučljivu inkrementaciju proizvoda. Sprintovi obično traju dve nedelje, ali po potrebi mogu biti i duži.

Ipak, kada je razvoj softvera u pitanju, čak i par nedelja može biti jako jako dugačak period. Zamislimo kako se jedan sprint može lako pretvoriti u noćnu moru?

Na samom startu sprinta developer pušuje neke izmene koje ne prolaze test. Kako tim ne primenjuje Kontinualnu integraciju, niko ne primećuje greške nedelju dana. Na kraju sprinta, pre puštanja u proizvodnju, developeri rade sve testove kako bi bili sigurni da je sve u redu. Samo u ovom trenutku tim detektuje problem, sprint se “lomi” i dolazi do probijanja rokova.

Greška je mogla da bude primećena samo nekoliko minuta nakon pušovanja, ali kako nije bilo automatizovanog sistema tim je potrošio dragoceno vreme tokom sprinta umesto da je odmah izvršio popravku.

Češća integracija koda vodi smanjenju rizika na bilo kom projektu. Dokle god postoje pravi pokazatelji koji prate “zdravlje” aplikacije, defekti koda mogu biti primećeni i popravljeni brže. Kada razvojni tim integriše svoj posao češće to znači da je razlika između trenutnog stanja aplikacije i onog koje poseduje developer manja.

Kontinualna integracija podrazumeva proces automatskog testiranja svake promene u okviru celokupnog koda što je ranije moguće. Automatizovano testiranje nije alat pomoću kojeg se gradi bolji softver, već proces za izgradnju proizvoda za vaše korisnike.

Inicijalni  trošak  postavljanja CI sistema će biti nadmašen uštedom radnih sati koji će biti sačuvani kao posledica.

Pronalaženje baga u samom procesu razvoja je najjeftiniji mogući način, jer u kasnijim fazama ovaj trošak samo raste. Uz to, neki od novijih CI sistema se postavljaju prilično lagano, tako da troškovi nisu preterano veliki.

Na primer, postavljanje servisa poput Codeship-a traje samo nekoliko minuta (mada se plaća i zahteva korišćenje GitHuba ili BitBucketa). Razmislite o tome kakav je vaš trenutni QA proces i koji njegovi delovi mogu biti zamenjeni dobrim CI sistemom.

Ovde u Devani, mi umesto termina Quality Assurance više insistiramo na terminu  Quality Advocacy i smatramo da je CI jedan od sjajnih načina za njegovu implementaciju.

Kod Kontinualne integracije bitan je tim, ne alati.

Iako je Kontinualna integracija sjajna stvar, što su codebase, a i tim, veći tako će se češće javljati problemi i biće potrebno više vremena da se reše.

Timovi neretko nakon par nedelja počinju da ignorišu crvene flegove koje ‘diže’ Jenkins, uglavnom jer postoje neki drugi prioriteti.  Product owneri često ne razumeju značaj “clean bullda” a tehničke vođe ne mogu da kupe vreme za popravljanje unit testova.

Ako ste započeli implementaciju, a niste sigurni da li idete u pravom smeru, bacite pogled na listu: 34 znaka da vam CI ne funkcioniše.