Разумевање континуиране интеграције и континуиране примене

Da li ste čuli za CI/CD, ali niste sigurni šta tačno predstavlja?

U idealnom scenariju, softverski inženjeri rade na pisanju koda koji se zatim šalje u produkciono okruženje, kako bi ga krajnji korisnici mogli upotrebljavati. Da bi se ispunili poslovni zahtevi (koji često dolaze od korisnika/klijenata), neophodno je da softverski proizvodi budu bez grešaka.

Uobičajen pristup koji praktikuju softverski inženjeri podrazumeva rad u odvojenim granama (branches), a zatim kreiranje zahteva za spajanje (pull request) koji ažurira glavnu granu novim promenama. Dobra praksa je i pisanje testova kako bi se osiguralo da nove izmene ne uvode greške. Kada programeri rade na novoj funkcionalnosti, često ne kreiraju zahtev za spajanje dok u potpunosti ne završe sa njenim razvojem. Tada se dešava sledeće:

  • Provode mnogo vremena pokušavajući da usklade svoj kod sa promenama koje su se u međuvremenu dogodile u glavnoj produkcionoj grani.
  • Zatim moraju da rešavaju brojne sukobe prilikom spajanja koda.
  • Postoji i rizik da naruše stabilnost produkcione grane, što dodatno utiče na druge programere koji rade na projektu.

Ako ste se ikada našli u ovoj situaciji, složićete se da je to prilično frustrirajuće – niko ne voli da provodi radni dan na taj način.

Koje je rešenje?

Kontinuirana Integracija

Video objašnjenje

Da bi se izbegli gore navedeni problemi, inženjerski timovi mogu usvojiti praksu koja se naziva kontinuirana integracija. Kao što i samo ime sugeriše, ona podrazumeva konstantno integrisanje promena koda koje programeri prave u zajedničku granu ili repozitorijum. Kod koji se integriše mora proći kroz seriju verifikacionih testova kako bi se osiguralo da ne narušava funkcionalnost aplikacije. Integracija se vrši samo nakon što testovi prođu.

Da bismo ovo bolje razumeli, zamislimo tim od 10 programera. Oni lokalno kreiraju grane u kojima pišu kod za implementaciju određenih funkcionalnosti. Umesto da šalju zahteve za spajanje kada u potpunosti završe sa celom funkcionalnošću, oni se odlučuju da ih šalju čim naprave manje izmene. Primer takve izmene bi mogao biti kreiranje novog modala, recimo, ako programer radi na funkciji koja korisnicima omogućava upravljanje pojedinačnim zadacima u aplikaciji. Umesto da čeka da se cela funkcionalnost završi, programer odmah šalje ovu manju promenu i kreira zahtev za spajanje.

Pre nego što se ova nova izmena integriše, potrebno je izvršiti niz testova.

Softverski inženjerski timovi koriste alate kao što je Travis CI za kreiranje ovih integracionih procesa i testova. Sa ovakvim alatima, testovi su automatizovani i pokreću se čim se zahtev za spajanje pošalje ka ciljnoj grani.

Rezultati testova se generišu, a programer koji je kreirao zahtev za spajanje može videti rezultate i izvršiti neophodne izmene. Prednosti pridržavanja ovog modela integracije malih količina koda i testiranja su sledeće:

  • Tim lako može utvrditi šta je uzrokovalo neuspeh procesa izgradnje ili testa. Ovo umanjuje šanse za puštanje greške u produkciono okruženje.
  • Ako je proces automatizovan, tim ima više vremena da se fokusira na produktivnost.

Važno je napomenuti da ova praksa ohrabruje tim da često šalje kod u glavnu granu. Ovo, međutim, ne bi bilo efikasno ukoliko drugi članovi tima ne bi redovno preuzimali izmene iz glavne grane kako bi ažurirali svoje lokalne repozitorijume.

Vrste testova

Prilikom pisanja testova koji će biti deo procesa integracije, evo nekih koji se mogu primeniti:

  • Integracioni testovi – kombinuju pojedinačne softverske jedinice i testiraju ih kao celinu.
  • Jedinični testovi – testiraju pojedinačne jedinice ili komponente softvera, kao što su metode ili funkcije.
  • UI testovi – potvrđuju da softver dobro funkcioniše iz perspektive korisnika.
  • Prihvatni testovi – testiraju da li softver ispunjava poslovne zahteve.

Važno je napomenuti da nije neophodno testirati sve navedeno, jer je veliki deo ovih testova možda već pokriven kodom koji je napisao programer.

Alati za kontinuiranu integraciju

Bez detaljnijeg razmatranja, evo nekih alata koje možete početi da koristite u vašim postojećim ili novim projektima:

  • Travis CI – poznat u open source svetu i obećava besprekorno testiranje vašeg koda za nekoliko minuta.
  • Circle CI – pruža vam snagu, fleksibilnost i kontrolu za automatizaciju vašeg procesa od kontrolisanja verzija do implementacije.
  • Jenkins – nudi stotine dodataka za podršku razvoju, implementaciji i automatizaciji bilo kog projekta.

Ako ste novi u korišćenju Jenkinsa, predlažem da pogledate ovaj Udemy kurs kako biste naučili kontinuiranu integraciju sa Javom i .NET-om.

Kontinuirana Implementacija

Ne bi bilo dobro ako bi funkcionalnost koju napravite stajala u repozitorijumu nedeljama ili mesecima pre nego što se implementira u produkciono okruženje. Pored integracije manjih izmena u glavnu granu, inženjerski timovi bi trebali ove izmene što pre implementirati u produkciono okruženje.

Cilj kontinuirane implementacije je da se promene učine dostupnim korisnicima čim programeri integrišu te izmene u glavnu granu.

Kao i u slučaju kontinuirane integracije, i ovde se koriste automatizovani testovi i verifikacije kako bi se osiguralo da su nove izmene verifikovane. Implementacija se vrši samo ukoliko ovi testovi prođu.

Da bi tim imao koristi od prakse kontinuirane implementacije, neophodno je da ima:

  • Automatizovano testiranje je ključni aspekt svih kontinuiranih inženjerskih praksi. U slučaju kontinuirane implementacije, kod koji se implementira mora biti u skladu sa standardima koje je tim postavio. Idealno bi bilo da, ako nova izmena ne zadovoljava kriterijume, test ne prođe i izmena se ne integriše.
  • Iako su automatizovani testovi veoma korisni, moguće je da se neke greške ipak provuku u produkciono okruženje. U takvim slučajevima, neophodno je da tim bude u mogućnosti da poništi izmenu koja je napravljena – „poništi implementaciju“. Ovo bi trebalo da vrati produkcioni kod na stanje pre nove izmene.
  • Sistemi za praćenje su neophodni kako bi se pratile izmene koje su implementirane u produkciono okruženje. Ovo omogućava timu da prati greške na koje korisnici nailaze koristeći nove promene.

Navedeni alati za kontinuiranu integraciju takođe pružaju funkcionalnosti za postavljanje sistema kontinuirane implementacije. Mnogo je alata o kojima možete pročitati više.

Zaključak

Produktivnost razvojnog tima je ključna za uspeh poslovanja. Da bi se osigurala produktivnost, moraju se usvojiti prakse koje to podstiču. Kontinuirana integracija i kontinuirana implementacija su odlični primeri takvih praksi.

Uz kontinuiranu integraciju, timovi mogu svakodnevno da šalju veliku količinu koda. Kada se to postigne, postaje lako implementirati nove promene korisnicima što je pre moguće. Implementacijom ovih izmena, dobijaju se povratne informacije od korisnika. Na kraju, kompanija može da inovira na osnovu dobijenih povratnih informacija, što je dobitak za sve.

Takođe možete naučiti kako da unapredite i optimizujete CI/CD proces.

Ako ste programer i zainteresovani ste za učenje CI/CD-a, pogledajte ovaj sjajan kurs.

Da li ste uživali u čitanju članka? Zašto ga ne biste podelili sa drugima?