🥇Seitsme kõige levinuma vea vältimine CI/CD kasutuselevõtul

Kui teie ettevõte on alles DevOpsi või CI/CD tööriistade rakendamisele minemas, võib teil olla kasulik tutvuda kõige levinumate vigadega, et neid mitte korrata ja mitte teiste äpardustele jalgu jääda.

Meeskond Mail.ru Cloud Solutions tõlkis artikli Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi koos täiendustega.

Valmisoleku puudumine kultuuri ja protsesside muutmiseks

Kui vaadata tsüklilist diagrammi DevOps, siis on näha, et DevOps praktikas on testimine pidev töö, mis on iga eraldi juurutamise põhielement.

DevOps'i lõputu tsükliline diagramm

Testimine ja kvaliteedi tagamine arendus- ja edastamisprotsessides on kõike, mida arendajad teevad, kohustuslik osa. See nõuab mõtteviisi muutmist, et testimine kaasata igasse ülesandesse.

Testimine muutub iga meeskonnaliikme igapäevaeluks. Üleminek pidevale testimisele ei toimu lihtsalt, sellele tuleb ette valmistuda.

Tagasiside puudumine

DevOps'i tõhusus sõltub pidevast tagasisidest. Jätkuv parandus ei ole võimalik, kui ei ole ruumi koostööks ja suhtlemiseks.

Ettevõtetel, kes ei korralda retrospektiivide kohtumisi, on keeruline rakendada pideva tagasiside kultuuri CI/CD-s. Retrospektiivide kohtumisi peetakse iga iteratsiooni lõpus, kus grupi liikmed arutavad, mis läks hästi ja mis halvasti. Retrospektiivid on Scrum/Agile'i alus, kuid need on vajalikud ka DevOps'i jaoks.

See tuleneb sellest, et retrospektiivide kohtumised kasvatavad harjumust tagasiside ja arvamuste vahetamiseks. Üks kõige olulisemaid aspekte alustades on korduvate retro-kohtumiste korraldamine, et need oleksid arusaadavad ja tuttavad kogu kollektiivile.

Kui rääkida tarkvara kvaliteedist, vastutavad kõik meeskonna liikmed selle hoidmise eest. Näiteks võivad arendajad kirjutada mooduliteste ja luua koodi, mis arvestab testitavust, aidates vähendada riske juba alguses.

Üks lihtsamaid viise, kuidas käsitleda muutunud arusaamu testimisest, on nimetada testijaid mitte QA-eks, vaid tarkvaratestijateks või kvaliteedinsenerideks. See muutus võib tunduda liiga lihtne või isegi rumal. Kuid kui kedagi nimetatakse "tarkvara kvaliteedi spetsialistiks", annab see vale arusaama sellest, kes vastutab toote kvaliteedi eest. Agile, CI/CD ja DevOps praktikas vastutavad kõik tarkvara kvaliteedi eest.

Teine oluline aspekt on arusaamine, mida kvaliteet tähendab kogu meeskonna ja iga selle liikme, organisatsiooni, ja huvigruppide jaoks.

Vale arusaam etapi lõpetamisest

Kui kvaliteet on pidev ja ühiselt jagatud protsess, on vajalik ühtne arusaam etapi lõpetamisest. Kuidas mõista, et etapp on lõpetatud? Mis juhtub, kui etapp märgitakse Trello tahvlil või muul kanban-tahvlil lõpetatuks?

Lõpetatud etapi määratlemine (DoD) on võimas tööriist CD DevOps/CI kontekstis. See aitab paremini mõista meeskonna ehitamise kvaliteedistandardeid.

Arendusmeeskond peab otsustama, mida tähendab "Valmis". Neil tuleb istuda ja koostada nimekiri omadustest, mis peavad olema täidetud igas etapis, et seda saaks pidada lõpetatuks.

DoD muudab protsessi läbipaistvamaks ning hõlbustab CI/CD rakendamist, kui see on kõigile meeskonna liikmetele selge ja ühiselt kooskõlastatud.

Mugavikuid ja selgelt määratletud eesmärkide puudumine

See on üks kõige sagedamini tsiteeritud soovitusi, kuid seda tasub uuesti rõhutada. Iga tõsise ettevõtmise, sealhulgas CI/CD või DevOpsi rakendamise, edu jaoks tuleb seada reaalseid eesmärke ja mõõta tulemuslikkust nende suhtes. Mida proovite CI/CD abil saavutada? Kas see võimaldab kiiremini välja anda versioone parema kvaliteediga?

Kõik seatud eesmärgid peavad olema mitte ainult läbipaistvad ja realistlikud, vaid ka kooskõlas ettevõtte praeguste tegevustega. Näiteks, kui tihti vajavad teie kliendid uusi parandusi või versioone? Ei ole mõtet protsesse ülekoormata ja versioone kiiremini välja anda, kui sellest ei ole kasutajatele lisaväärtust.

Lisaks ei pea te alati rakendama nii CD-d kui ka CI-d. Näiteks kõrge regulatsiooniga ettevõtted, nagu pangad ja meditsiinikliinikud, saavad töötada ainult CI-ga.

CI on hea lähtepunkt igasuguste DevOps-i rakendavate ettevõtete jaoks. Selle rakendamine toob ettevõttes märkimisväärseid muutusi tarkvaraga varustamise lähenemisviisides. Kui CI on omandatud, võib hakata mõtlema kogu protsessi parendamisele, kiirele väljalaskmisele ja teistele muudatustele.

Paljudele organisatsioonidele piisab vaid ühest CI-st, ja CD tuleks rakendada ainult siis, kui see toob lisaväärtust.

Sobivate jälgimisplaatide ja meetrikate puudumine

Kui eesmärgid on paika pandud, võib arendustiim luua jälgimisplaadi KPI-de mõõtmiseks. Enne selle väljatöötamist on mõistlik hinnata jälgitavaid parameetreid.

Erinevad raportid ja rakendused on kasulikud erinevatele meeskonna liikmetele. Scrum-meistritele on olulisem staatuse ja katvuse jälgimine, samas kui tippjuhtkond võib olla rohkem huvitatud spetsialistide väsimuse kiirusest.

Mõned meeskonnad kasutavad CI/CD staatuse hindamiseks juhtpaneele, millel on punased, kollased ja rohelised indikaatorid, et mõista, kas nad teevad kõike õigesti või on tekkinud viga. Punane tähendab, et tuleb tähelepanu pöörata sellele, mis toimub.

Kuid kui infopaneelid ei ole standardiseeritud, võivad need eksitada. Analüüsige, millised andmed on kõigile vajalikud, ja looge seejärel standardiseeritud kirjeldus, mida need tähendavad. Uurige, mis on osalejate jaoks mõistlikum: graafikud, tekst või numbrid.

Käsitsi testimise puudumine

Testimise automatiseerimine loob vundamendi heaks CI/CD toruks. Kuid automatiseeritud testimine igas etapis ei tähenda, et te ei peaks käsitsi testima.

Tõhusa CI/CD toru ehitamiseks on vajalikud ka käsitsi testid. Alati on olemas mõned testimise aspektid, mis nõuavad inimese analüüsi.

Võiksite mõelda käsitsi testimise jõupingutuste integreerimisele torusse. Pärast seda, kui mõned käsitsi testimise näidised on lõpetatud, saate liikuda juurutamisetappi.

Ärge proovige teste parandada

Tõhus CI/CD konveier nõuab ligipääsu vajalikele tööriistadele, olgu need siis testimise haldamine või integreerimine ja pidev jälgimine.

Kvaliteedile suunatud tugevate kultuuride loomine keskendub testide juurutamisele, klientidega suhtlemise jälgimisele pärast juurutamist ja parenduste jälgimisele.

Siin on mõned praktilised näpunäited, mida saab hõlpsasti teostada:

Veenduge, et testid oleksid kergesti kirjutatavad ja piisavalt paindlikud, et mitte katkeda koodi refaktoreerimisel.
Arendustiimid peaksid olema kaasatud testimisprotsessi — nägema nimekirja kasutajatest, probleemidest ja taotlustest, mis on CI konveierite jooksul testimise jaoks olulised.
Teie testide täielik katvus võib puududa, kuid jälgige alati, et kasutajakogemusele ja klientidega suhtlemisele olulised vood oleksid testitud.

Viimane, kuid mitte vähem oluline punkt

CI/CD-le minejamine algab tavaliselt alt üles, kuid lõpuks on see muundamine, mis nõuab juhtkonna osalust ning ettevõtte ajakulu ja resursse. CI/CD on oskuste kogum, protsessid, tööriistad ja kultuuri muutmine, selliseid muudatusi saab ellu viia ainult süsteemselt.

Mida veel teemast lugeda:

Allikas: habr.com