Postoji obilje sadržaja koji opisuje što su kontinuirana integracija, kontinuirana isporuka i kontinuirana implementacija. Ali čemu uopće služe ti procesi?
Ključno je razumjeti probleme koje CI i CD rješavaju kako bi ih pravilno koristili. To će omogućiti vašem timu da poboljša vaš postupak i izbjegne ulaganje napora u progonjenje fantastičnih mjernih podataka koji vašem procesu ne donose nikakvu vrijednost.
Neprekidna integracija je timski problem
Ako radite u timu, postoji vjerojatnost da nekoliko programera radi na istom spremištu. U spremištu se nalazi glavna grana koja nosi najnoviju verziju koda. Programeri rade na različitim stvarima na različitim granama. Kad netko završi sa promjenom, gurnut će je ili spojiti u glavnu granu. Na kraju će cijeli tim povući ovu promjenu.
Scenarij koji želimo izbjeći jest da neispravan predaj dođe do glavne grane. Neispravan znači da se kod ne prevodi ili se aplikacija neće pokrenuti ili je neupotrebljiva. Zašto? Ne zato što je aplikacija neispravna ili zato što svi testovi moraju uvijek biti zeleni. To nije problem - možete odlučiti da ne primenite tu verziju i pričekate popravak.
Problem je u tome što je cijeli vaš tim zapeo. Svi programeri koji su povukli pogrešno urezivanje provest će 5 minuta pitajući se zašto to ne radi. Nekolicina će vjerojatno pokušati pronaći pogrešno urezivanje. Neki će pokušati riješiti problem sami paralelno s neispravnim autorom koda.
Ovo je gubljenje vremena za vaš tim. Najgore je što ponovljeni incidenti potiču nepovjerenje u glavnu granu i potiču programere da rade odvojeno.
Kontinuirana integracija je sve u sprečavanju loma glavne grane kako vaš tim ne bi zapeo. To je to. Ne radi se o tome da svi vaši testovi budu stalno zeleni i da se glavna grana rasporedi u produkciju pri svakom urezivanju.Proces kontinuirane integracije neovisan je o bilo kojem alatu. Možete ručno potvrditi da spajanje vaše grane i glavne grane radi lokalno, a zatim spoj samo zapravo gurnuti u spremište. Ali to bi bilo vrlo neučinkovito. Zbog toga se kontinuirana integracija provodi pomoću automatiziranih provjera.
Provjere osiguravaju da, na minimumu:
- Aplikacija bi trebala biti izrađena i pokrenuta
- Većina kritičnih značajki trebala bi biti funkcionalna u svakom trenutku (putovanje prilikom prijave / prijave i ključne poslovne značajke)
- Uobičajeni slojevi aplikacije na koje se oslanjaju svi programeri trebali bi biti stabilni. To znači jedinstvene testove na tim dijelovima.
U praksi to znači da morate povući bilo koji okvir za jedinstveno testiranje koji vam odgovara i osigurati uobičajene slojeve aplikacije. Ponekad to nije toliko koda i to se može učiniti prilično brzo. Također morate dodati "test dima" kojim se potvrđuje da se kod kompilira i da se aplikacija pokreće. To je posebno važno u tehnologijama s ludim injekcijama ovisnosti poput Java Spring ili .NET jezgre. U velikim projektima tako je lako pogrešno povezati svoje ovisnosti da je potvrda da aplikacija uvijek počinje nužna.
Ako imate stotine ili tisuće testova, ne morate ih sve pokretati za svako spajanje. Trebat će vam puno vremena, a većina testova vjerojatno provjerava značajke "blokatora bez tima".U sljedećim ćemo odjeljcima vidjeti kako će postupak kontinuirane isporuke dobro iskoristiti ove brojne testove.
Nije stvar u alatima
Alati i automatizirane provjere su u redu. Ali ako vaši programeri spoje samo divovske grane na kojima rade tjednima, neće vam pomoći. Tim će potrošiti dosta vremena spajajući grane i popravljajući nekompatibilnosti koda koje će na kraju nastati. To je gubljenje vremena koliko i blokiranje neispravnim urezivanjem.
Kontinuirana integracija ne odnosi se na alate. Radi se o radu u malim dijelovima i integriranju vašeg novog koda u glavnu granu te čestom povlačenju.Često znači barem svakodnevno. Zadatak na kojem radite podijelite na manje zadatke. Spojite svoj kod vrlo često i povucite vrlo često. Na ovaj način nitko ne radi odvojeno dulje od dan ili dva, a problemi nemaju vremena da postanu grude snijega.
Veliki zadatak ne mora biti sve u jednoj grani. Nikad ne bi trebalo biti. Tehnike spajanja nedovršenog rada s glavnom granom nazivaju se "grananje apstrakcijom" i "prebacivanje značajki". Pogledajte post na blogu Kako započeti s kontinuiranom integracijom za više pojedinosti.
Ključne točke za dobru CI izgradnju
Vrlo je jednostavno. Neka bude kratko. 3-7 minuta treba biti maks. Nije stvar u CPU-u i resursima. Riječ je o produktivnosti programera. Prvo pravilo produktivnosti je fokus. Učinite jednu stvar, završite je, a zatim prijeđite na sljedeću stvar.
Promjena konteksta skupa je. Studije pokazuju da je potrebno oko 23 minute da se duboko preusmjerite na nešto kad vas uznemire.
Zamislite da gurnete svoju granu da biste je spojili. Započinjete drugi zadatak. Provodite 15-20 minuta ulazeći u to. Minutu nakon što se nađete u zoni, primit ćete obavijest o "neuspješnoj gradnji" iz vaše 20-minutne CI gradnje za prethodni zadatak. Vratite se da to popravite. Guraš ga opet. Lako ste izgubili više od 20 minuta krećući se naprijed-natrag.
Pomnožite 20 minuta jednom ili dva puta dnevno s brojem programera u vašem timu ... To je mnogo izgubljenog dragocjenog vremena.Sad zamislite da li su povratne informacije došle u roku od 3 minute. Vjerojatno uopće ne biste započeli novi zadatak. Morali biste imati dokaz da ste još jednom pročitali kôd ili pregledali PR dok ste čekali. Došla bi neuspjela obavijest i vi biste je popravili. Tada biste mogli prijeći na sljedeći zadatak. To je vrsta fokusa koji bi vaš proces trebao omogućiti.
Ako vam kratka izrada CI-a bude kratka, to predstavlja zamjenu. Testovi koji traju dulje ili daju malu vrijednost u kontekstu CI-a trebali bi se premjestiti na korak CD-a. I da, i tamo treba otkloniti kvarove. No budući da oni nikoga ne sprečavaju da radi svoje, popravke možete uzeti kao "sljedeći zadatak" kad završite s onim što radite. Samo isključite obavijesti tijekom rada i provjerite svako malo. Neka se prebacivanje konteksta na minimum.
Kontinuirana isporuka i postavljanje tehnički su problemi
Pomirimo se s definicijama da to maknemo s puta.
Kontinuirana isporuka je u vezi s mogućnošću postavljanja bilo koje verzije koda u svako doba. U praksi to znači zadnju ili pretposljednju verziju vašeg koda. Ne implementirate se automatski, obično zato što to ne morate ili su ograničeni životnim ciklusom vašeg projekta. Ali čim se nekome učini, raspoređivanje se može obaviti u minimalnom vremenu. Taj netko može biti test / QA tim koji želi testirati stvari u scenskom ili predprodukcijskom okruženju. Ili zapravo može doći vrijeme za uvođenje koda u proizvodnju.
Ideja kontinuirane isporuke je pripremiti artefakte što bliže onome što želite pokretati u svom okruženju. To mogu biti datoteke .jar ili .war ako radite s Javom ili izvršne datoteke ako radite s .NET-om. To također mogu biti mape prepisanog JS koda ili čak Docker spremnici, što god čini implementaciju kraćom (tj. Unaprijed ste izgradili onoliko koliko možete unaprijed).
Pripremajući artefakte, ne mislim pretvoriti kod u artefakte. To je obično nekoliko skripti i minuta izvršenja. Priprema znači:
Pokrenite sve moguće testove kako biste osigurali da će kôd jednom biti implementiran, a da će zaista raditi. Pokrenite jedinstvene testove, integracijske testove, testove od kraja do kraja, pa čak i testove performansi ako to možete automatizirati.Na taj način možete filtrirati koje su verzije vaše glavne grane zapravo spremne za proizvodnju, a koje nisu. Idealan testni paket:
- Osigurava da ključne funkcije aplikacije rade. Idealno sve funkcionalnosti
- Osigurava da nije uveden nijedan prekidač za izvedbu, tako da kada nova verzija pogodi vaše brojne korisnike, ima priliku potrajati
- Pokrenite bilo kakvo ažuriranje baze podataka koje vaš kôd treba kako biste izbjegli iznenađenja
Ne treba biti vrlo brz. Prihvatljivo je 30 minuta ili 1 sat.
Kontinuirano postavljanje je sljedeći korak. Najsavremeniju verziju koda koja je spremna za proizvodnju instalirate u neko okruženje. Idealno za produkciju ako dovoljno vjerujete svom CD testnom paketu.
Imajte na umu da, ovisno o kontekstu, to nije uvijek moguće ili vrijedno truda. Kontinuirana isporuka često je dovoljna da biste bili produktivni, pogotovo ako radite u uskoj mreži i imate ograničena okruženja u koja se možete rasporediti. Može biti i da ciklus izdavanja vašeg softvera sprječava neplanirana postavljanja.
Kontinuirana isporuka i kontinuirana primena (nazovimo ih od sada CD-a) nisu problemi u timu. Radi se o pronalaženju prave ravnoteže između vremena izvršavanja, napora na održavanju i relevantnosti vašeg paketa testova kako biste mogli reći "Ova verzija radi kako treba".
I to je ravnoteža. Ako vaši testovi traju 30 sati, to je problem. Pogledajte ovaj epski post o tome kako izgleda testni paket Oracle baze podataka. Ali ako potrošite toliko vremena na ažuriranje testova s najnovijim kodom da to sprečava napredak tima, ni to nije dobro. Također ako vaš testni paket ne osigurava gotovo ništa ... u osnovi je beskoristan.
U idealnom svijetu želimo jedan set artefakata koji se mogu rasporediti po predavanju glavnoj grani. Vidite da imamo problem vertikalne skalabilnosti: što brže prelazimo s koda na artefakte, to smo spremniji za implementaciju najnovije verzije koda.
Koja je velika razlika?
Neprekidna integracija problem je horizontalne skalabilnosti. Želite da programeri često spajaju svoj kôd, tako da provjere moraju biti brze. Idealno u roku od nekoliko minuta kako bi izbjegli da programeri cijelo vrijeme prebacuju kontekst uz vrlo asinhne povratne informacije iz CI gradnji.
Što više programera imate, veća računalna snaga vam je potrebna za pokretanje jednostavnih provjera (izrada i testiranje) na svim aktivnim granama.
Dobra izrada CI-ja: osigurava da se u glavnu granu ne uvede kôd koji razbija osnovne stvari i sprječava rad ostalih članova tima i da je dovoljno brz da programerima pruži povratne informacije u roku od nekoliko minuta kako bi se spriječilo prebacivanje konteksta između zadataka.Kontinuirana isporuka i primjena problemi su vertikalne skalabilnosti. Morate izvršiti jednu prilično složenu operaciju.
Dobra izrada CD-a: osigurava da što više značajki radi ispravno. Što je brže, to bolje, ali nije stvar u brzini. Izrada od 30-60 minuta je u redu.Uobičajena zabluda je doživljavanje CD-a kao problema s horizontalnom skalabilnošću poput CI-ja: što brže možete prijeći s koda na artefakte, više obveza zapravo možete obraditi i što ste bliži idealnom scenariju.
Ali to nam ne treba. Izrada artefakata za svako počinjenje i što je brže moguće, obično je pretjerana. Možete vrlo dobro pristupiti CD-u na najbolji mogući način: imajte jednu CD građu koja će odabrati samo najnoviju predaju za provjeru nakon što završi zadana gradnja.
Ne griješite s CD-om. Stvarno je teško. Dostizanje dovoljnog testnog pouzdanja da kažete da je vaš softver spreman za automatsku implementaciju obično radi na aplikacijama na niskim površinama poput API-ja ili jednostavnog korisničkog sučelja. To je vrlo teško postići na složenom korisničkom sučelju ili velikom monolitnom sustavu.
Zaključak
Alati i principi koji se koriste za izvršavanje CI i CD-a često su vrlo slični. Ciljevi su ipak vrlo različiti.
Kontinuirana integracija predstavlja kompromis između brzine povratne sprege prema programerima i važnosti provjera koje izvodite (izrada i testiranje). Nijedan kôd koji bi ometao napredak tima ne bi trebao doći do glavne grane.
Kontinuirana isporuka implementacije uključuje pokretanje što temeljitijih provjera kako biste uhvatili probleme na kodu. Kompletnost provjera je najvažniji čimbenik. Obično se mjeri u smislu pokrivenosti kodom ili funkcionalne pokrivenosti vaših testova. Rano hvatanje pogrešaka sprječava lomljenje koda u bilo kojem okruženju i štedi dragocjeno vrijeme vašeg testnog tima.
Izradite svoje CI i CD građevine kako biste postigli ove ciljeve i održali svoj tim produktivnim. Nijedan tijek posla nije savršen. Problemi će se pojaviti svako malo. Koristite ih kao naučene lekcije za jačanje vašeg radnog procesa svaki put kad to učine.
Objavljeno 27. studenog 2019. na blogu Fire CI.