ProHoster > Blogs > Administrācija > Septiņas visizplatītākās kļūdas, pārejot uz CI/CD

Septiņas visizplatītākās kļūdas, pārejot uz CI/CD

Septiņas visizplatītākās kļūdas, pārejot uz CI/CD
Ja jÅ«su uzņēmums tikai ievieÅ” DevOps vai CI/CD rÄ«kus, jums var bÅ«t noderÄ«gi iepazÄ«ties ar visbiežāk pieļautajām kļūdām, lai tās neatkārtotos un neuzkāptu uz kāda cita grābekļa. 

Komanda Mail.ru mākoņa risinājumi tulkojis rakstu Izvairieties no Ŕīm bieži sastopamajām kļūmēm, pārejot uz CI/CD, autors Jasmine Chokshi ar papildinājumiem.

Negatavība mainīt kultūru un procesus

Ja paskatās uz ciklisko diagrammu DevOps, ir skaidrs, ka DevOps praksē testÄ“Å”ana ir nepārtraukta darbÄ«ba, katras izvietoÅ”anas bÅ«tiska sastāvdaļa.

Septiņas visizplatītākās kļūdas, pārejot uz CI/CD
DevOps bezgalīgā cikla diagramma

TestÄ“Å”ana un kvalitātes nodroÅ”ināŔana izstrādes un piegādes laikā ir bÅ«tiska daļa no visa, ko izstrādātāji dara. Tas prasa domāŔanas maiņu, lai katrā uzdevumā iekļautu testÄ“Å”anu.

TestÄ“Å”ana kļūst par katra komandas locekļa ikdienas darba sastāvdaļu. Pāreja uz pastāvÄ«gu testÄ“Å”anu nav vienkārÅ”a, jums ir jābÅ«t tam gatavam.

Atsauksmju trūkums

DevOps efektivitāte ir atkarÄ«ga no pastāvÄ«gas atgriezeniskās saites. Nepārtraukta pilnveidoÅ”anās nav iespējama, ja nav vietas sadarbÄ«bai un komunikācijai.

Uzņēmumiem, kas nerÄ«ko retrospektÄ«vas sanāksmes, ir grÅ«ti ieviest nepārtrauktas atgriezeniskās saites kultÅ«ru CI/CD. Katras iterācijas beigās tiek rÄ«kotas retrospektÄ«vas sanāksmes, kuru laikā komandas locekļi apspriež, kas gāja labi un kas slikti. RetrospektÄ«vas sanāksmes ir Scrum/Agile pamats, taču tās ir nepiecieÅ”amas arÄ« DevOps. 

Tas ir tāpēc, ka retrospektÄ«vas sanāksmes ieaudzina ieradumu apmainÄ«ties ar atsauksmēm un viedokļiem. Viens no svarÄ«gākajiem punktiem sākumā ir atkārtotu retro sanāksmju organizÄ“Å”ana, lai tās kļūtu saprotamas un pazÄ«stamas visai komandai.

Runājot par programmatÅ«ras kvalitāti, visi komandas locekļi ir atbildÄ«gi par tās uzturÄ“Å”anu. Piemēram, izstrādātāji var rakstÄ«t vienÄ«bu testus un arÄ« rakstÄ«t kodu, paturot prātā pārbaudāmÄ«bu, palÄ«dzot samazināt risku jau no paÅ”a sākuma.

Viens vienkārÅ”s veids, kā atspoguļot izmaiņas domāŔanā par testÄ“Å”anu, ir izsaukt testētājus nevis kvalitātes nodroÅ”inātājus, bet gan programmatÅ«ras testētājus vai kvalitātes inženierus. Å Ä«s izmaiņas var Ŕķist pārāk vienkārÅ”as vai pat muļķīgas. Bet, nosaucot kādu par "programmatÅ«ras kvalitātes nodroÅ”ināŔanas personu", rodas nepareizs priekÅ”stats par to, kurÅ” ir atbildÄ«gs par produkta kvalitāti. Agile, CI/CD un DevOps praksē ikviens ir atbildÄ«gs par programmatÅ«ras kvalitāti.

Vēl viens svarīgs punkts ir saprast, ko kvalitāte nozīmē visai komandai un katram tās dalībniekam, organizācijai un ieinteresētajām pusēm.

Pārpratums par posma pabeigŔanu

Ja kvalitāte ir nepārtraukts un vispārējs process, ir nepiecieÅ”ama vienota izpratne par posma pabeigÅ”anu. Kā zināt, kad posms ir beidzies? Kas notiek, ja solis ir atzÄ«mēts kā pabeigts uz Trello vai cita Kanban paneļa?

Gatavā definīcija (DoD) ir spēcīgs rīks CD DevOps/CI kontekstā. Tas palīdz labāk izprast kvalitātes standartus tam, ko un kā komanda veido.

Izstrādes komandai ir jāizlemj, ko nozÄ«mē ā€œGatavsā€. Viņiem ir jāapsēžas un jāizveido raksturlielumu saraksts, kas jāievēro katrā posmā, lai to uzskatÄ«tu par pabeigtu.

DoD padara procesu caurspīdīgāku un atvieglo CI/CD ievieŔanu, ja to saprot visi komandas locekļi un par to vienojas.

Reālu, skaidri definētu mērķu trūkums

Å is ir viens no visbiežāk citētajiem padomiem, taču tas ir jāatkārto. Lai gÅ«tu panākumus jebkurā nozÄ«mÄ«gā darbā, tostarp CI/CD vai DevOps, jums ir jāizvirza reāli mērÄ·i un jāizvērtē veiktspēja, salÄ«dzinot ar tiem. Ko jÅ«s mēģināt panākt ar CI/CD? Vai tas nodroÅ”ina ātrāku izlaiÅ”anu ar labāku kvalitāti?

Jebkuriem izvirzÄ«tajiem mērÄ·iem jābÅ«t ne tikai pārskatāmiem un reālistiskiem, bet arÄ« jāatbilst uzņēmuma paÅ”reizējām darbÄ«bām. Piemēram, cik bieži jÅ«su klientiem ir nepiecieÅ”ami jauni ielāpi vai versijas? Nav nepiecieÅ”ams pārslogot procesus un ātrāk atbrÄ«vot, ja lietotājiem nav papildu ieguvumu.

Turklāt jums ne vienmēr ir jāievieÅ” gan CD, gan CI. Piemēram, stingri regulēti uzņēmumi, piemēram, bankas un medicÄ«nas klÄ«nikas, var strādāt tikai ar KI.

CI kalpo kā labs sākumpunkts jebkuram uzņēmumam, kas ievieÅ” DevOps. Kad tas tiek ieviests, uzņēmumu pieeja programmatÅ«ras piegādei bÅ«tiski mainās. Kad CI ir apgÅ«ts, varat domāt par visa procesa uzlaboÅ”anu, izlaiÅ”anas ātruma palielināŔanu un citām izmaiņām.

Daudzām organizācijām pietiek ar CI vien, un CD ir jāievieÅ” tikai tad, ja tas rada pievienoto vērtÄ«bu.

AtbilstoŔu informācijas paneļu un metrikas trūkums

Kad esat iestatÄ«jis savus mērÄ·us, izstrādes komanda var izveidot informācijas paneli KPI mērÄ«Å”anai. Pirms tā izstrādes ir vērts novērtēt parametrus, kas tiks uzraudzÄ«ti.

Dažādi pārskati un lietojumprogrammas ir noderÄ«gas dažādiem komandas locekļiem. Scrum Master vairāk interesē statuss un sasniedzamÄ«ba. Savukārt augstāko vadÄ«bu varētu interesēt speciālistu izdegÅ”anas lÄ«menis.

Dažas komandas izmanto arÄ« informācijas paneļus ar sarkaniem, dzelteniem un zaļiem indikatoriem, lai novērtētu CI/CD statusu, lai saprastu, vai viss tiek darÄ«ts pareizi, vai ir kļūda. Sarkans nozÄ«mē, ka jums ir jāpievērÅ” uzmanÄ«ba notiekoÅ”ajam.

Tomēr, ja informācijas paneļi nav standartizēti, tie var bÅ«t maldinoÅ”i. Analizējiet, kādi dati ikvienam ir nepiecieÅ”ami, un pēc tam izveidojiet standartizētu aprakstu par to, ko tie nozÄ«mē. Uzziniet, kas ieinteresētajām personām ir saprātÄ«gāks: grafika, teksts vai cipari.

Nav manuālu testu

TestÄ“Å”anas automatizācija veido pamatu labam CI/CD cauruļvadam. Taču automatizētā testÄ“Å”ana visos posmos nenozÄ«mē, ka nevajadzētu veikt manuālu testÄ“Å”anu. 

Lai izveidotu efektÄ«vu CI/CD cauruļvadu, ir jāveic arÄ« manuālas pārbaudes. Vienmēr bÅ«s daži testÄ“Å”anas aspekti, kuriem nepiecieÅ”ama cilvēka analÄ«ze.

Ir vērts apsvērt iespēju savā konveijerā integrēt manuālās testÄ“Å”anas pasākumus. Kad dažu testa gadÄ«jumu manuālā testÄ“Å”ana ir pabeigta, varat pāriet uz izvietoÅ”anas fāzi.

Nemēģiniet uzlabot pārbaudes

Efektīvam CI/CD konveijeram ir nepiecieŔama piekļuve pareizajiem rīkiem, neatkarīgi no tā, vai tā ir testu pārvaldība vai integrācija un pastāvīga uzraudzība.

SpēcÄ«gas, uz kvalitāti orientētas kultÅ«ras izveides mērÄ·is ir testu Ä«stenoÅ”ana, uzraugot klientu mijiedarbÄ«bu pēc izvietoÅ”anas un izsekojot uzlabojumus. 

Šeit ir daži praktiski padomi, kurus varat viegli īstenot:

  1. Pārliecinieties, vai jūsu testi ir viegli uzrakstāmi un pietiekami elastīgi, lai nepārkāptu, pārveidojot kodu.
  2. Izstrādes komandas ir jāiekļauj testÄ“Å”anas procesā ā€” skatiet sarakstu ar lietotāju problēmām un pieprasÄ«jumiem, kas ir svarÄ«gi pārbaudÄ«t CI konveijera laikā.
  3. Jums var nebūt pilns testa pārklājums, taču vienmēr pārliecinieties, ka tiek pārbaudītas plūsmas, kas ir svarīgas UX un klientu pieredzei.

Pēdējais, bet ne mazāk svarīgais punkts

Pāreja uz CI/CD parasti tiek virzÄ«ta no apakÅ”as uz augÅ”u, taču galu galā tā ir transformācija, kas no uzņēmuma prasa vadoÅ”o lomu, laiku un resursus. Galu galā CI/CD ir prasmju, procesu, rÄ«ku un kultÅ«ras pārstrukturÄ“Å”anas kopums; Ŕādas izmaiņas var Ä«stenot tikai sistemātiski.

Ko vēl lasīt par tēmu:

  1. Kā tehniskie parādi nogalina jūsu projektus.
  2. Kā uzlabot DevOps.
  3. Deviņas populārākās DevOps tendences 2020. gadā.

Avots: www.habr.com

Pievieno komentāru