IT Industrija
🔥 Najčitanije
🔥 Najčitanije
Kontinualna integracija je praksa koje pomaže developerima da isporuče bolji softver na pouzdaniji i predvidljiviji način.
Ovaj članak tiče se problema sa kojima se developeri suočavaju tokom pisanja, testiranja i dostavljanja softvera korisnicima. Istraživanjem kontinualne integracije, proći ćemo i kroz načine na koje možemo da prebrodimo te probleme.
Problem
Najpre, bacićemo pogled na sam uzrok problema, koji leži u ciklusu razvoja softvera. Potom, proći ćemo kroz neke od konflikta pri promeni koji se mogu dogoditi tokom tog procesa, i konačno ćemo doći do glavnih faktora zbog kojih ovi problemi eskaliraju, prateći ih objašnjenjem kako kontinualna integracija rešava ove probleme.
Uzrok problema
Pogledajmo kako izgleda tradicionalni ciklus razvoja softvera. Svaki developer dobija kopiju koda sa centralnog repozitorijuma. Početna tačka je, uglavnom, najnovija stabilna verzija date aplikacije. Svi developeri počinju sa radom na istom mestu, i rade na dodavanju nove karakteristike ili popravljanju baga.
Svaki developer napreduje radeći samostalno ili u grupi. Dodaju ili menjaju klase, metode i funkcije, oblikujući kod prema svojim potrebama, i eventualno obavljaju svoj zadatak.
U međuvremenu, ostali developeri i timovi nastavljaju sa radom na svojim zadacima, menjajući ili dodavajući kod, rešavajući probleme koje su dobili.
Ukoliko se odmaknemo i osmotrimo širu sliku, npr. ceo projekat, možemo primetiti da svi developeri koji rade na projektu pri radu na izvornom kodu menjaju kontekst ostalim developerima.
Kada timovi budu obavili svoje zadatke, kopiraće svoj kod na centralni repozitorijum. U tom momentu imamo dva moguća scenarija.
- Kod u centralnom repozitorijumu ostaje neizmenjen
Kod će biti isti kao početna kopija. Ukoliko se ovo dogodi, sve je jednostavno, zbog toga što je sistem neizmenjen. Sve ideje koje smo imali u vezi sa sistemom još uvek važe.
Ovo se uvek dešava ako si jedini developer koji radi na aplikaciji ili ako si završio svoj posao pre ostalih članova svog tima. Kako god, za tebe je sve sjajno. Sistem koji si kreirao i testirao se može dostaviti korisnicima bez dodatnih izmena.
- Kod u centralnom repozitorijumu je promenjen
Druga mogućnost je da se aplikacija na kojoj si radio izmenila, i ovo otkriješ kada pokušaš da prekopiraš kod na centralni repozitorijum. Promene u tom kodu mogu a i ne moraju biti u konfliktu sa onima koje si ti načinio u svom.
Ukoliko postoje konflikti, potrebno ih je rešiti da bi se kod uspešno dostavio korisnicima. U ovom slučaju, svašta bi se moglo zakomplikovati.
U daljem tekstu ćemo istražiti tipove konflikta koji se mogu dogoditi i šta ćete možda morati da uradite da biste ih rešili.
Konflikti pri promeni
Postoji nekoliko tipova konflikta pri promeni koji se mogu dogoditi pri integraciji koda. Navešćemo nekoliko najčešćih tipova. Počećemo sa najjednostavnijim situacijama, i postepeno ćemo istražiti složenije.
- Implementacioni detalji su se izmenili – Refaktorisao si metodu, ali je to isto uradio i developer koji je već integrisao njegov kod u centralni repozitorijum. Ponašanje te metode je isto u sve tri implementacije. Potrebno je da odaberete verziju koja odgovara i odbacite ostale implementacije. Čak možete i smisiti četvrtu implementaciju. Ovo je jednostavan tip konflikta, koji se uglavnom razrešava za nekoliko minuta.
- API-i na koje ste se oslanjali su se izmenili – Na primer, ponašanje izvesne metode se promenilo. Ovo bi moglo uticati na vaš kod na bilo koji način – od manjih promena koje ćete morati da načinite do većih strukturalnih promena. Ne postoji čarobno rešenje u tom slučaju. Moraćete da pažljivo proučite izmene i načinite popravke.
- Ceo jedan podsistem aplikacije se ponaša na drugačiji način – u ovakvim slučajevima ćete svakako učiniti delimičnu, ako ne i potpunu, izmenu vašeg koda. Ukoliko je ovo slučaj, verovatno ćete morati da porazgovarate sa svim developerima koji rade na aplikaciji, jer takva velika izmena ne bi smela da se desi bez prethodnog obaveštavanja ostatka tima.
Ove i mnoštvo drugih prepreka bi se mogle pojaviti, izazvane raznim faktorima. Različite verzije frameworkova, biblioteka i baza podataka su još jedan potencijalni uzrok problema.
Kada ste već apdejtovali kod tako da ga je moguće kompajlirati ili interpretirati, takođe treba da se setite da ponovo pokrenete sve testove koje ste prethodno izvršili.
Ovi primeri ukazuju na to da se količina potrebnog rada za rešavanje problema koji je prvobitno zadat developeru može vrlo lako duplirati.
Faktori koji izazvaju eskalaciju problema
Navešćemo neke od glavnih faktora koji mogu izazvati eskalaciju ovih problema.
- Veličina tima koji radi na projektu. Broj izmena koje se vraćaju na glavni repozitorijum je proporcionalan broju ljudi koji rade na projektu. Ovo čini proces integracije koda u centralnom repozitorijumu značajno težim.
- Količina proteklog vremena od momenta kada je developer dobio najnoviju verziju koda sa centralnog repozitorijuma. Kako vreme prolazi, ostatak ljudi koji rade na projektu integrišu sve više i više njihovog rada i menjaju kontekst u kojem vaš kod treba da radi. Ponekada su promene u glavnom repozitorijumu toliko velike da je lakše da potpuno izmenite vaš kod.
Veliki broj izmena u sistemu može učiniti integraciju još kompleksnijom i može imati ogromno dejstvo na produktivnost tima. Takve situacije se čak nazivaju „integracionim paklom”.
Ovaj proces ima mnoštvo negativnih posledica po vašu firmu. Testiranje i ispravljanje bagova može trajati večno. Kasnite sa izlaskom aplikacije. Timovi su van sebe od stresa zbog dugih i nepredvidljivih ciklusa izbacivanja aplikacije i moral opada.
Rešenje: Integrišite kontinualno
Rešenje problema koji se javlja pri radu sa velikim brojem izmena pri velikim integracionim događajima je konceptualno jednostavno. Potrebno je samo izdeliti te velike integracione događaje u mnogo manje. Na ovaj način, developeri moraju da se nose sa značajno manjim brojem izmena, koje se lakše razumeju i lako je nositi se s njima. Da bi se integracioni događaji smanjili i bili lakši za rukovođenje potrebno je da se dešavaju češće. Nekoliko puta dnevno je idealno. Često rađenje malih integracija se nekada naziva kontinualnom integracijom.
Ideja je jednostavna, ali se često čini nemogućom za implementaciju. To se događa jer promena procesa zahteva da promenimo naše navike, a menjanje navika je teško.
Korišćenje kontinualne integracije
Da bi izbegli prethodno opisane prepreke, developeri treba da integrišu njihov delimično obavljen posao u glavni repozitorijum svakodnevno ili čak nekoliko puta dnevno. Da bi ovo obavili, prvo moraju da prikupe sve promene načinjene na glavnom repozitorijumu koje su se dogodile tokom njihovog rada na kodu. Takođe treba da se uvere da će njihov kod raditi kada se bude integrisao u glavni repozitorijum. Jedini način da se ovo osigura jeste da se testira svaka karakteristika aplikacije.
Prvo što padne na pamet kada počnemo da razmatramo kontinualnu integraciju je da će developeri morati da provode polovinu njihovog vremena svakog dana testirajući kod tako da se ne bi pokvario kod u glavnom repozitorijumu.
Zato je zahtev za kontinualnu integraciju posedovanje automatskih testova. Automatizovani testovi uklanjaju breme ručnog, repetitivnog i greškama sklonog procesa testiranja sa developera. Takođe i ubrzavaju proces testiranja. Računar može obaviti nešto što bi bili sati ručnog testiranja sa samo nekoliko minuta automatizovanog testiranja. „Behavior-driven” i „test-driven development” su tehnike razvijanja koda koje pomažu developerima pri pisanju čistog, održivog koda i pritom pisanja testova istovremeno.
Testovi imaju smisla samo ako se obave svakog puta kada se promeni izvorni kod, bez izuzetka. Alatke za kontinualnu integraciju poput Semaphore-a su alatke koje automatizuju ovaj proces tako što motre na centralni repozitorijum koda i izvršavaju testove prilikom svake izmene izvornog koda. Pored toga što obavljaju testove, takođe skupljaju rezultate testova i saopštavaju rezultate celom timu koji radi na projektu.
Rezultat kontinualne integracije je toliko važan da mnogi timovi imaju pravilo da obustave rad na njihovom trenutnom zadatku ukoliko je verziji u centralnom repozitorijumu potrebna popravka. Udružuju se sa timom koji već radi na ispravljanju koda dokle god taj kod ne prođe sve testove. Uloga koju alatka kontinualne integracije igra u svemu tome je poboljšanje komunikacije među developerima saopštavajući im stanje izvornog koda projekta.
Kako usvojiti kontinualnu integraciju
Kontinualna integracija značajno doprinosi unapređenju razvojnog procesa, ali isto tako zahteva suštinske promene u svakodnevnoj razvojnoj rutini. Izazovi usvajanja kontinualne integracije su jednostavni, ukoliko se proces kontinualne integracije uvodi postepeno.
Jedan od najvećih izazova sa kojima se timovi suoče je nedostatak automatskih testova. Dobar recept za prevazilaženje ove prepreke je dodavanje automatizovanih testova za svaku karakteristiku tokom njenog razvoja. Istovremeno, developer koji radi na ispravljanju baga bi takođe trebalo da pokriva kod koji ispravlja testovima. Kada god se bag prijavi, tim bi prvo trebalo da napiše test koji bi trebalo da demonstrira postojanje baga. Kada se popravka izvrši, kod bi trebalo da prođe test.
Kako vreme bude prolazilo, suite za automatizovano testiranje postepeno će postajati sveobuhvatniji i developeri će se sve više oslanjati na njega. Usvajanje alatke za kontinualnu integraciju da bi se saopštilo stanje testova celom timu u ranoj fazi projekta je takođe važno, zbog toga što celom timu podiže svest o stanju projekta.
Zaključak
Uvođenje kontinualne integracije i automatizovanog testiranja u razvojni proces menja način na koji se softver razvija od temelja. Zahteva napor od strane svih članova tima i kulturološku promenu u organizaciji.
Velike izmene u workflowu se teško brzinski uvode. Promene se moraju događati postepeno, i svi članovi tima i akteri treba da budu saglasni sa idejom. Edukacija članova tima o kontinualnoj integraciji i stvaranju alatke za automatizovano testiranje treba da se radi sistematski. Kada se prvi koraci načine, proces se uglavnom nastavi sam od sebe, jer i developeri i ostali akteri sami uvide korist okruženja za automatizovano testiranje i bezbrižnost koju ono donosi celoj ekipi.
Članak je prvobitno objavljen na Semaphore blogu i preveden i objavljen na Startitu uz dozvolu autora.