5 uobičajenih zamki CI / CD-a i kako ih izbjeći

Devops su možda jedan od najmagljivijih pojmova u razvoju softvera, ali većina se od nas slaže da pet aktivnosti čini devops onim što jest: kontinuirana integracija, kontinuirana isporuka, cloud infrastruktura, automatizacija ispitivanja i upravljanje konfiguracijom. Ako radite ovih pet stvari, radite devops. Jasno je da je svih pet važno kako bi se ispravilo, ali previše lako da se pogriješi. Konkretno, kontinuirana integracija i kontinuirana isporuka (CI / CD) mogu biti najteži devopsovi potezi za svladavanje.

Kontinuirana integracija (CI) postupak je u kojem programeri i testeri zajednički potvrđuju novi kôd. Tradicionalno su programeri pisali kôd i integrirali ga jednom mjesečno za testiranje. To je bilo neučinkovito - pogreška u kodu od prije četiri tjedna mogla bi natjerati programere da revidiraju kod napisan prije tjedan dana. Da bi prevladao taj problem, CI ovisi o automatizaciji za kontinuirano integriranje i testiranje koda. Scrum timovi koji svakodnevno koriste CI kod za uređivanje najmanje, dok se većina njih obvezuje za svaku uvedenu promjenu.

Kontinuirana isporuka (CD) postupak je kontinuiranog stvaranja artefakata koji se mogu osloboditi. Neke tvrtke korisnicima puštaju jednom ili čak više puta dnevno, dok druge iz tržišnih razloga sporiji tempo objavljuju. U svakom slučaju, sposobnost otpuštanja kontinuirano se ispituje. Stalna implementacija moguća je zahvaljujući oblačnim okruženjima. Poslužitelji su postavljeni tako da ih možete rasporediti u produkciju bez isključivanja i ručnog ažuriranja poslužitelja.

Stoga je CI / CD postupak za kontinuirani razvoj, testiranje i isporuku novog koda. Neke tvrtke poput Facebooka i Netflixa koriste CI / CD za dovršavanje 10 ili više izdanja tjedno. Druge se tvrtke trude postići taj tempo jer podlegnu jednoj ili više od pet zamki o kojima ću razgovarati sljedeće.

Zamka za CI / CD # 1: Prvo automatiziranje pogrešnih procesa

Ova zamka teži udaru organizacija koje prelaze sa razvoja vodopada na devops. Nova organizacija ima prednost u primjeni CI / CD-a od nule. Postojeće tvrtke moraju postupno putovati od ručnog do visoko automatiziranog razvoja. Potpuni prijelaz može potrajati nekoliko mjeseci, što znači da morate biti iterativni u načinu na koji usvajate CI / CD.

Kada pitate: "Treba li to sada automatizirati?" prođite kroz sljedeći kontrolni popis:

  1. Koliko se često ponavlja postupak ili scenarij?
  2. Koliko traje proces?
  3. Koji su ljudi i ovisnosti o resursima uključeni u proces? Uzrokuju li kašnjenja u CI / CD-u?
  4. Je li proces sklon pogreškama ako nije automatiziran?
  5. Koja je hitnost automatizacije postupka?

Koristeći ovaj kontrolni popis, možete dati prioritet koracima u implementaciji CI / CD-a. Prvo i najvažnije, automatizirajte postupak sastavljanja koda. U idealnom slučaju integrirat ćete kôd više puta dnevno (1). Ručno postupak traje nekoliko minuta do nekoliko sati (2). To zaustavlja izlaz dok prevoditelj ne završi zadatak (3). Također je podložan ljudskim pogreškama (4), a budući da je CI / CD cjeloviti san bez automatizirane integracije, ovo je hitno (5).

Možemo pokrenuti isti kontrolni popis na testiranju. Dok prelazite na CI / CD, mogli biste se zapitati: Trebamo li najprije automatizirati funkcionalno testiranje ili testiranje korisničkog sučelja? Obje će se ponoviti najmanje jednom dnevno (1). Oboje može potrajati dva do tri sata za aplikaciju srednje veličine (2). Ali oni uključuju višestruke ovisnosti (3). Ako automatizirate funkcionalno testiranje, možda nećete morati tako često ažurirati skriptu za automatizaciju. S druge strane, korisničko sučelje često se mijenja i stoga zahtijeva česte promjene skripti. Iako su obje podložne pogreškama (4), prije testiranja korisničkog sučelja trebali biste dati prednost funkcionalnom testiranju kako biste najbolje iskoristili svoje resurse (5).

Ponovimo to još jednom s postupkom postavljanja okruženja. Ovaj se scenarij često ponavlja samo ako ste zaposlenik ili imate veliku odbojnost (1). To je prilično dugotrajan postupak koji može potrajati nekoliko sati, ako ne i nekoliko dana (2). Novi članovi tima ne mogu učiniti ništa korisno bez okruženja, pa očito postoji ovisnost i kašnjenje (3). Ne bih rekao da je postupak podložan pogreškama (4), pa je li još uvijek hitan (5)? Naginjem prema da, ali ipak bih prvo dao prednost integraciji i funkcionalnom testiranju.

Ne postoji takva stvar kao prekomjerna automatizacija. Da imate neograničene resurse, automatizirali biste sve moguće. To znači da ne možete postići potpunu automatizaciju ispitivanja. Ponekad možete rastaviti zadatke na manje segmente i automatizirati zakrpe. Ponekad biste jednostavno trebali detaljno dokumentirati postupak i ručno ga izvršiti.

Zamka za CI / CD # 2: Zbunjujuće kontinuirano postavljanje za kontinuiranu isporuku

Kontinuirano postavljanje koncept je da će se svaka promjena u osnovi koda gotovo odmah primijeniti na proizvodnju ako su rezultati cjevovoda uspješni. To je zastrašujuće za većinu organizacija jer brze promjene proizvoda mogu uplašiti korisnike.

Tvrtke vjeruju da ako ne prakticiraju kontinuiranu implementaciju, ne rade CD. Ne uspijevaju razlikovati kontinuirano raspoređivanje i kontinuiranu isporuku.

Kontinuirana isporuka koncept je da svaka promjena baze koda prolazi kroz cjevovod do točke primjene u neproizvodna okruženja. Tim pronalazi i rješava probleme odmah, ne kasnije kada planiraju objaviti bazu koda.

Baza koda uvijek je na razini kvalitete koja je sigurna za objavljivanje. Kada je puštanje baze koda u proizvodnju poslovna odluka.

Iako kontinuirano raspoređivanje uznemirava većinu organizacija, kontinuirana isporuka rezonira s njima. Kontinuirana isporuka daje im kontrolu nad uvođenjem proizvoda, funkcionalnošću i čimbenicima rizika. Ima vremena za alfa testiranje, za beta kupce, za one koji rano usvoje itd.

Zamka za CI / CD # 3: Nedostatak značajnih nadzornih ploča i mjernih podataka

U implementacijama CI / CD-a, scrum tim može stvoriti nadzornu ploču prije nego što članovi znaju što trebaju pratiti. Kao rezultat, tim postaje plijen logične zablude: "Ovo su mjerni podaci koje imamo, pa moraju biti važni." Umjesto toga, izvedite progresivnu procjenu prije dizajniranja nadzorne ploče.

Različiti članovi IT organizacije, pa čak i različiti članovi scrum tima, imaju različite prioritete. Na primjer, ljudi u mrežnom operativnom centru (NOC) vole crvene, žute i zelene indikatore. Takve nadzorne ploče na semaforu omogućuju osoblju NOO-a da razlikuje probleme bez čitanja gustog teksta ili oporezivanja njihovih analitičkih sposobnosti. Semafori pomažu u upravljanju stotinama poslužitelja.

Možda ćete doći u napast da i za CI / CD koristite nadzornu ploču na semaforu. Green, na putu smo. Žuti, nismo u pravu, ali imamo plan da to riješimo. Crveni, nismo u pravu i vjerojatno ćemo morati promijeniti svoje ciljeve.

Ta je nadzorna ploča vjerojatno korisna scrum masteru, ali što je s VP-om za razvoj ili tehničkim direktorom? Ako Scrum tim ima 350 sati posla za dvotjedni sprint, a njegovih 10 članova odgovara po 35 sati, dobili bi odgovarajući broj bodova. Viši menadžment mogao bi biti manje zainteresiran za status priča i više znatiželjan o stopi "sagorijevanja": brzini izvršenja zadatka. Nose li članovi tima svoj teret? Koliko brzo Poboljšavaju li se s vremenom?

Nažalost, stope sagorijevanja mogu dovesti u zabludu ako različiti dionici ne razumiju dogovorene navike scrum tima. Neke momčadi sagorijevaju bodove što prije. Ostali čekaju pred kraj sprinta kako bi sagorjeli otvorene točke. Nadzorna ploča to bi trebala uzeti u obzir.      

Ako možete procijeniti koje podatke svi žele i uspostaviti standardni narativ o tome što ti podaci znače, tada možete osmisliti korisnu nadzornu ploču. Ali nemojte opsjedati supstancu nauštrb izgleda. Pitajte kako dionici žele da to izgleda. Bi li grafikoni, tekst ili brojevi bili najbolji?

Ovo su razmatranja koja treba istražiti u progresivnoj procjeni. Oni ilustriraju kako je nezgodno izraditi korisnu CI / CD nadzornu ploču - i usrećiti sve. Preglasno, najglasniji član tima otme postupak, a drugi se osjećaju frustrirano što nadzorna ploča udovoljava željama samo jedne osobe. Slušajte sve.  

Zamka za CI / CD # 4: Nedostatak koordinacije između kontinuirane integracije i kontinuirane isporuke

Ova zamka vraća nas na našu konsenzusnu definiciju devopa, koja smatra da su kontinuirana integracija i kontinuirana isporuka dvije različite stavke. CI hrani CD. Provedba pristojnog cjevovoda za kontinuiranu integraciju i cjelovitog kontinuiranog isporučivanja traje mjesecima i zahtjeva suradnju. Osiguranje kvalitete, tim devopsa, inženjeri operativnog sustava, scrum majstori - svi moraju pridonijeti. Možda je najteži aspekt CI / CD-a ovaj ljudski faktor, a ne bilo koji tehnički izazov o kojem smo razgovarali. Kao što ne možete programirati zdrav odnos između dvoje ljudi, ne možete automatizirati suradnju i komunikaciju.

Da biste procijenili ovu razinu koordinacije, usporedite svoj CI / CD postupak s najboljima u poslu. Tvrtke poput Netflixa mogu dovršiti integraciju, testiranje i isporuku u roku od dva do tri sata. Uspostavili su sustav koji prenosi kod iz ruke u ruku bez neodlučnosti i rasprave. Ne, nije 100 posto automatiziran jer je to s trenutnom tehnologijom nemoguće.

Zamka za CI / CD # 5: Balansiranje učestalosti izvođenja poslova kontinuirane integracije i korištenja resursa

Poslovi kontinuirane integracije trebali bi se pokretati za svaku promjenu koja se uvede u kod. Uspješni poslovi dopuštaju promjene da prolaze dok ih neuspjesi odbijaju. To potiče programere da provjeravaju manje dijelove koda, što pokreće više gradnji u danu. Međutim, nepotrebni poslovi kontinuirane integracije troše resurse, što troši vrijeme i novac.

Budući da ovaj proces uključuje puno iskorištavanja resursa (CPU, snaga, vrijeme), softver bi trebao biti razbijen na manje komponente kako bi se stvorili brži cjevovodi. Ili bi poslovi kontinuirane integracije trebali biti dizajnirani za grupne prijave koje se prvo testiraju lokalno. Cilj je pronaći ravnotežu između učestalosti izvršavanja poslova kontinuirane integracije i korištenja resursa.

Držite cilj na vidiku

Dok istražujemo zamke CI / CD-a - zajedno sa svom njegovom ezoteričnom terminologijom - lako je izgubiti iz vida zašto je ovo važno. U konačnici, CI / CD je neophodan jer ispunjava poslovne ciljeve.

Tehnološki rukovoditelji znaju da kontinuirana evolucija, brzi popravci i kvalitetni rezultati stvaraju i zadržavaju kupce. Znaju da neuspjelo izdanje poziva palicu na recenzije App Storea, a povratak visokih recenzija teže je zadržati. Devopi bi mogli stvoriti bolje radno iskustvo za vaš tim, ali zato tvrtke ne primjenjuju devops.

Jednostavno rečeno, zamke CI / CD-a vrijedi pregledati jer su u pitanju milijarde dolara. Iako ne predlažem da na svoju nadzornu ploču CI / CD dodate oznaku dionica ili program za praćenje recenzija App Storea, molim vas da i dalje budete svjesni toga. Mnogo ovisi o detaljima CI / CD-a.

Zubin Irani suosnivač je i izvršni direktor cPrimea, savjetodavnog poduzeća s kompletnim uslugama koje provodi agilne transformacije i nudi agilna rješenja za više od 50 tvrtki iz Fortune 100 i mnoge od najvećih poslodavaca u Silicijskoj dolini.

New Tech Forum pruža mjesto za istraživanje i raspravu o novonastaloj tehnologiji poduzeća u neviđenoj dubini i širini. Izbor je subjektivan, zasnovan na našem odabiru tehnologija za koje vjerujemo da su važne i da najviše zanimaju čitatelje. ne prihvaća marketinške kolaterale za objavljivanje i zadržava pravo uređivanja cjelokupnog sadržaja. Pošaljite sve upite na [email protected]