🥇Seitsme kõige levinuma vea vältimine CI/CD üleminekul

Kui teie ettevõte alles tutvustab DevOpsi või CI/CD tööriistu, võib teil olla kasulik tutvuda kõige levinumate vigadega, et neid mitte korrata ja mitte astuda teistele jälgedesse.

Meeskond Mail.ru Pilve Lahendused tõlkinud artikli Vältige neid levinud takistusi CI/CD-le üleminekul, autor Jasmine Chokshi koos lisadega.

Valmiduse puudumine kultuuri ja protsesside muutmiseks

Kui vaadata tsüklilist diagrammi DevOps, siis paistab, et DevOpsi praktikates on testimine pidev töö, mis on igas eraldi deploymendis fundamentaalne osa.

Lõputu tsükliline diagramm DevOps

Testimine ja kvaliteedikontroll arendamise ja tarnimise protsessis on kohustuslik osa kõigest, mida arendajad teevad. See nõuab mõtteviisi muutmist, et kaasata testimine iga ülesande juurde.

Testimine muutub iga meeskonnaliikme igapäevaseks töö osaks. Üleminek pidevale testimisele ei toimu lihtsalt, selleks tuleb olla valmis.

Tagasiside puudumine

DevOpsi efektiivsus sõltub pidevast tagasisidest. Jätkuv paranemine ei ole võimalik, kui ei ole ruumi koostööks ja suhtlemiseks.

Ettevõtetel, kes ei korralda retrospektiivte, on raske luua CI/CD-s pideva tagasiside kultuuri. Retrospektiivid toimuvad iga iteratsiooni lõpus, kus grupi liikmed arutavad, mis läks hästi ja mis halvasti. Retrospektiivid on Scrum/Agile alus, kuid need on vajalikud ka DevOpsis.

See tuleneb sellest, et retrospektiivide kaudu harjutatakse tagasiside ja arvamuste vahetamist. Üks olulisemaid aspekte alguses on korduvate retrospektiivide organiseerimine, et need muutuksid arusaadavaks ja harjumuseks kogu meeskonnale.

Kui rääkida tarkvara kvaliteedist, kannavad kõik meeskonnaliikmed vastutust selle säilitamise eest. Näiteks saavad arendajad kirjutada mooduliteste ja kirjutada koodi testimise arvessevõtmiseks, aidates vähendada riske alates algusest.

Üks lihtsamaid viise testimise arusaamade muutuste peegeldamiseks on nimetada testijaid mitte QA-ks, vaid tarkvaratestijateks või kvaliteediinsenerideks. See muudatus võib tunduda liiga lihtne või isegi naeruväärne. Kuid kui kedagi nimetatakse "tarkvarakvaliteedi spetsialistiks", luuakse vale ettekujutus, kes vastutab toote kvaliteedi eest. Agile, CI/CD ja DevOps praktikas kannavad kõik vastutust tarkvara kvaliteedi eest.

Teine oluline punkt on mõista, mida kvaliteet tähendab kogu meeskonnale ja iga meeskonnaliikme, organisatsiooni ja sidusrühmade jaoks.

Vale arusaam etapi lõpetamisest

Kui kvaliteet on pidev ja ühine protsess, on vajalik ühiselt mõista etapi lõpetamist. Kuidas teada, et etapp on lõpetatud? Mida juhtuda, kui etapp on Trello või muu kanban-lauda peal märgitud lõpetatuks?

Valmisoleku määratlemine (DoD) on võimas tööriist CD DevOps / CI kontekstis. See aitab paremini mõista kvaliteedistandardeid, mida meeskond ehitab ja kuidas.

Arendajate meeskond peab otsustama, mida tähendab "Valmis". Neil tuleb istuda ja koostada nimekiri omadustest, mis peavad igal etapil olema täidetud, et seda saaks lugeda lõpetatuks.

DoD muudab protsessi läbipaistvamaks ja lihtsustab CI/CD rakendamist, kui see on kõigile meeskonna liikmetele selge ja ühiselt kokku lepitud.

Realistlike, selgelt määratletud eesmärkide puudumine

See on üks kõige tihedamini tsiteeritud nõuandeid, kuid see tasub kordamist. Iga tõsise ettevõtmise, sealhulgas CI/CD või DevOps'i rakendamise edu saavutamiseks on vaja seadistada realistlikud eesmärgid ja mõõta tulemuslikkust nende suhtes. Mida te püüate CI/CD abil saavutada? Kas see võimaldab kiiremalt välja anda uusi 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 sageli teie kliendid vajavad uusi parandusi või versioone? Ei ole mõtet üle koormata protsesse ja välja anda versioone kiiremini, kui sellest ei ole kasutajatele lisahüvesid.

Lisaks ei ole alati vajalik rakendada nii CD-d kui CI-d. Näiteks võivad kõrgelt reguleeritud organisatsioonid, nagu pangad ja meditsiinikliinikud, töötada ainult CI-ga.

CI on hea lähtepunkt igale ettevõttele, kes juurutab DevOps'i. Selle rakendamine muudab oluliselt tarkvaraarenduse lähenemisviise. Kui CI on omandatud, võib kaaluda kogu protsessi täiustamist, väljalaskekiirusest ja muudest muudatustest.

Paljudele organisatsioonidele piisab ainult CI-st, ja CD tuleks rakendada ainult siis, kui see toob lisandusväärtust.

Sobivate jälgimispaneelide ja näitajate puudumine

Kui olete seadnud eesmärgid, saab arendajate meeskond luua jälgimispaneeli KPI-de mõõtmiseks. Enne selle väljatöötamist tasub hinnata parameetreid, mida jälgitakse.

Erinevad aruanded ja rakendused on erinevatele meeskonnaliikmetele kasulikud. Scrum-meistrid on rohkem huvitatud olekust ja katvusest. Samal ajal võib tippjuhtkonnas olla huvi spetsialistide töökoormuse kiirus.

Mõned meeskonnad kasutavad ka CI/CD oleku hindamiseks armatuurlaudu, kus on punased, kollased ja rohelised indikaatorid, et mõista, kas nad teevad kõik õigesti või on tekkinud viga. Punane tähendab, et olukorrale tuleb tähelepanu pöörata.

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. Selgitage välja, mis on huvipoolte jaoks mõtestatum: diagrammid, tekst või numbrid.

Manuaalsete testide puudumine

Testimise automatiseerimine loob tugeva aluse CI/CD konveierile. Kuid automatiseeritud testimine kõigil etappidel ei tähenda, et te ei peaks manuaalset testimist läbi viima.

Tõhusa CI/CD konveieri loomiseks on vajalikud ka manuaalsed testid. Alati on mõned testimise aspektid, mis nõuavad inimese analüüsi.

Väärt on kaaluda manuaalsete testide koormuse integreerimist konveierisse. Kui mõned testimised on lõpetatud, saate liikuda juurutamise etappi.

Ärge proovige teste täiustada

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

Kvaliteedile suunatud tugeva kultuuri loomine keskendub testide juurutamisele, kliendiga suhtlemise jälgimisele pärast juurutamist ja täiustuste jälgimisele.

Siin on mõned praktilised näpunäited, mida saate lihtsalt ellu viia:

Veenduge, et testid oleksid kergesti kirjutatavad ja piisavalt paindlikud, et mitte puruneda koodi refaktoorimisel.
Arendustiimid peavad olema kaasatud testimisprotsessi — nägema loendit kasutajaprobleemidest ja taotlustest, mis on olulised CI konveierite testimise ajal.
Teil ei pruugi olla täielikku katvust testidega, kuid jälgige alati, et kasutajakogemuse ja kliendiga suhtlemise jaoks olulised vood oleksid testitud.

Viimane, kuid mitte vähem oluline punkt

Üleminek CI/CD-le algab tavaliselt alt üles, kuid lõpuks on see transformatsioon, mis nõuab juhtkonna osalemist, aja ja ressursside paigutamist ettevõttesse. Lõppude lõpuks on CI/CD oskuste kogum, protsessid, tööriistad ja kultuuriülesehitus, mida saab selliste muudatuste juurutamiseks teha ainult süsteemselt.

Mida veel selle kohta lugeda:

Allikas: habr.com