Razumijevanje kontinuirane integracije i kontinuirane implementacije

Čuo sam CI / CD, ali niste sigurni što je to?


U idealnom slučaju softverski su inženjeri angažirani za pisanje koda koji treba otpremiti u proizvodno okruženje kako bi ga tvrtka koja treba proizvod mogla iskoristiti. Da biste zadovoljili posao (koji se često nazivaju korisnici / klijenti), ključno je da proizvodi bez grešaka.

Tipičan pristup koji slijede softverski inženjeri je rad u granama i stvaranje zahtjeva za povlačenjem koji ažurira matičnu granu s novim ažuriranim ažuriranjem. Usvojili smo praksu pisanja testova kao sredstva kojim se osigurava da nove promjene ne unose bugove. Kada programeri rade na značajci u većini slučajeva, oni često ne stvaraju zahtjev za povlačenjem dok u potpunosti ne urade s tom značajkom. Ono što se dogodi kad budu spremni je to;

  • Oni provode puno vremena pokušavajući uskladiti svoju bazu kodova s ​​promjenama koje su se dogodile u proizvodnoj grani dok su radili.
  • Pri tome moraju popraviti niz sukoba spajanja.
  • Također postoji mogućnost da oni prekinu proizvodnu granu, što utječe i na one koji povuku iz grane prije nego što se problem vidi i riješi.

Ako ste ikada bili u takvoj situaciji, složit ćete se da to može biti bol – nitko ne želi voljeti tako provoditi svoj radni dan.

Što je rješenje?

Kontinuirana integracija

https://www.youtube.com/watch?v=HnWuIjUw_Q8

Kako bih spriječio gore navedene scenarije; inženjerski timovi mogu usvojiti zvanu praksu kontinuirana integracija – kao što ime sugerira, uključuje kontinuiranu integraciju promjena koda koje su uložili programeri u zajedničku podružnicu / spremište. Kôd koji treba integrirati mora proći provjereni test kako bi se osiguralo da ne prekida aplikaciju. Integriran je tek kada test prođe

Da bismo to razumjeli, zamislimo stvarni scenarij u kojem postoji tim od 10 programera. Ti programeri lokalno stvaraju podružnicu u koju pišu kod za implementaciju određenih značajki. Umjesto slanja zahtjeva za povlačenje kada su u potpunosti gotovi sa značajkom, odlučuju slati zahtjeve za povlačenjem jer unose male promjene. Primjer takve promjene bit će stvaranje novog modalusa, pod pretpostavkom da programer radi na značajci koja korisnicima omogućuje upravljanje pojedinačnim zadacima u aplikaciji. Umjesto da čeka dok se značajka zadatka dovrši, da se pridržava neprekidnog obrasca integracije, programer pritisne ovu malu promjenu (u usporedbi s onim na čemu radi) i stvori potezni zahtjev za spajanje koda.

Prije integriranja ove nove promjene treba provesti niz testova.

Timovi softverskog inženjeringa koriste alate poput Travis CI za stvaranje ovih integracijskih procesa i testova. Pomoću ovakvih alata testovi se automatiziraju, tako da se pokreću nakon što se zahtjev za povlačenje podnese u ciljnu granu odabranu tijekom postavljanja..

Rezultati testova se generiraju, a programer koji je stvorio zahtjeve za povlačenje može vidjeti rezultate i izvršiti potrebne promjene. Prednosti pridržavanja ovog obrasca integriranja koda što je manje moguće i provođenja provjerenog testa su;

  • Tim koji radi sudjeluje može znati što je uzrokovalo da proces sastavljanja ili ispitivanja ne uspije. Na taj se način smanjuje mogućnost otpreme buba u proizvodnju.
  • Ako tim automatizira proces, imat će luksuz vremena da se usredotoče na produktivnost.

Važno je napomenuti u ovoj praksi da potiče tim da često gura kod glavne grane. To će biti neučinkovito ako se ostali članovi tima ne povuku iz glavne podružnice da bi ažurirali svoje lokalno spremište.

Vrste testova

Pisanje testova koji će biti dio procesa integracije, evo nekoliko koji se mogu primijeniti u procesu:

  • Integracija – kombinira pojedinačne jedinice softvera i testira ih kao skupinu.
  • Jedinica – testira pojedinačne jedinice ili komponente softvera poput metoda ili funkcija.
  • UI – tvrdi da softver dobro funkcionira iz perspektive korisnika.
  • Prihvaćanje – testovi koje softver ispunjava u skladu s poslovnim zahtjevima.

Važno je napomenuti da ne morate sve to testirati, jer je pregršt njih možda već pokriven kodom koji je napisao programer.

Alati za kontinuiranu integraciju

Ne ulazeći u dubinu, evo alata koje možete početi koristiti u svojim trenutnim ili novim projektima;

  • Travis CI – poznat u svijetu otvorenog koda i obećava vam da ćete svoj kôd bez problema testirati u nekoliko minuta.
  • Krug CI – pruža vam snagu, fleksibilnost i kontrolu za automatizaciju cjevovoda od kontrole do implementacije.
  • Jenkins – pruža stotine dodataka za podršku stvaranju, implementaciji i automatizaciji bilo kojeg projekta.

Ako ste novi u Jenkinsu, onda bih vam predložio da ovo uzmete Udemy tečaj naučiti CI s Java i .NET.

Kontinuirana primjena

Kakve će koristi biti ako značajka koju ugrađujete leži u skladištu tjednima ili mjesecima prije nego što se primijeni u proizvodno okruženje. Koliko god inženjerski timovi mogli raditi na integriranju malih promjena u glavnu granu, što god se dogodilo, oni također mogu te promjene ugurati u proizvodno okruženje što je prije moguće..

Cilj kada se praktikuje kontinuirana implementacija je spustiti promjene na korisnike čim programeri integriraju te promjene u glavnu granu.

Kao i u slučaju kontinuirane integracije, pri korištenju kontinuirane implementacije postavljaju se automatizirani testovi i provjere kako bi se osiguralo da se novo integrirane promjene provjere. Uvođenje se događa samo kad prođu ovi testovi.

Da bi tim imao koristi od prakse kontinuiranog postavljanja, moraju imati sljedeće:

  • Automatizirano testiranje je temeljna okosnica svih kontinuiranih inženjerskih praksi. U slučaju kontinuirane primjene, kôd koji se mora primijeniti mora odgovarati standardu koji je tim postavio za ono što namjeravaju izbaciti krajnjim korisnicima. U idealnom slučaju, ako je nova promjena ispod praga, test bi trebao uspjeti i ne bi se integrirao. Inače, to postaje integrirano.
  • Iako su automatizirani testovi uzvratni, moguće je da će neke greške kliznuti u proizvodno okruženje. Za to je potrebno da tim može poništiti napravljenu promjenu – poništiti raspoređivanje. Ovo bi trebalo pretvoriti proizvodni kod na ono što je bilo prije nove promjene.
  • Sustavi praćenja potrebni su za praćenje promjena koje su gurnute u proizvodno okruženje. Tako tim može pratiti greške s kojima se korisnici susreću prilikom korištenja razmještenih razmještaja.

Spomenuti alati za kontinuiranu integraciju također vam pružaju funkciju za postavljanje sustava kontinuiranog pokretanja. Postoji puno njih o kojima također možete pročitati.

Zaključak

Produktivnost razvojnog tima ključna je za uspjeh poslovanja. Da bi se osigurala njihova produktivnost, moraju se usvojiti prakse koje to potiču. Kontinuirana integracija i implementacija su primjeri takve prakse.

Uz stalnu integraciju, timovi mogu gurati što više koda dnevno. Uz ovo postignuto, postaje lako što prije implementirati nove dodane promjene korisniku. Uvođenjem ovih promjena moguće je dobiti povratne informacije od korisnika. Na kraju će se posao moći inovirati na temelju dobivenih povratnih informacija, što je dobit od svih za sve.

Ako ste programer i zainteresirani ste za učenje CI / CD-a, provjerite ovo sjajan tečaj.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map