Kui teie ettevõte alles tutvustab DevOpsi või CI/CD tööriistu, võib olla kasulik tutvuda levinumate vigadega, et neid mitte korrata ja mitte kellegi teise reha peale astuda.
Meeskond tõlkinud artikli .
Valmisolematus kultuuri ja protsesside muutmiseks
Kui vaadata tsüklilist diagrammi , on selge, et DevOpsi tavade puhul on testimine pidev tegevus, iga juurutamise põhiosa.
DevOpsi lõpmatu tsükli diagramm
Testimine ja kvaliteedi tagamine arenduse ja tarnimise ajal on oluline osa kõigest, mida arendajad teevad. See nõuab mõtteviisi muutust, et lisada testimine igasse ülesandesse.
Testimisest saab iga meeskonnaliikme igapäevatöö osa. Üleminek pidevale testimisele ei ole lihtne, selleks tuleb valmis olla.
Tagasiside puudumine
DevOpsi efektiivsus sõltub pidevast tagasisidest. Pidev täiustamine on võimatu, kui pole ruumi koostööks ja suhtlemiseks.
Ettevõtetel, kes ei korralda retrospektiivseid koosolekuid, on CI/CD-s pideva tagasiside kultuuri juurutamine keeruline. Iga iteratsiooni lõpus peetakse tagasivaatavaid koosolekuid, mille käigus meeskonnaliikmed arutavad, mis läks hästi ja mis halvasti. Retrospektiivsed koosolekud on Scrumi/Agile’i aluseks, kuid need on vajalikud ka DevOpsi jaoks.
Seda seetõttu, et tagasivaatavad kohtumised sisendavad harjumust tagasisidet ja arvamusi vahetada. Üheks olulisemaks punktiks stardis on korduvate retrokohtumiste korraldamine, et need muutuksid arusaadavaks ja tuttavaks kogu meeskonnale.
Tarkvara kvaliteedi osas vastutavad selle säilitamise eest kõik meeskonnaliikmed. Näiteks saavad arendajad kirjutada ühikuteste ja ka koodi kirjutada, pidades silmas testitavust, aidates algusest peale riski vähendada.
Üks lihtne viis testimisest mõtlemise muutuse kajastamiseks on kutsuda testijaid mitte kvaliteedikontrolliks, vaid tarkvara testijateks või kvaliteediinseneriks. See muudatus võib tunduda liiga lihtne või isegi rumal. Kuid kellegi "tarkvara kvaliteedi tagamise isikuks" nimetamine annab vale ettekujutuse selle kohta, kes vastutab toote kvaliteedi eest. Agile'i, CI/CD ja DevOpsi tavade puhul vastutavad kõik tarkvara kvaliteedi eest.
Teine oluline punkt on mõista, mida tähendab kvaliteet kogu meeskonna ja selle iga liikme, organisatsiooni ja sidusrühmade jaoks.
Väärarusaam etapi lõpetamisest
Kui kvaliteet on pidev ja üldine protsess, on vaja ühtset arusaama etapi valmimisest. Kuidas sa tead, kui etapp on läbi? Mis juhtub, kui Trello või mõnel muul Kanbani tahvlil on etapp märgitud lõpetatuks?
Valmis määratlus (DoD) on CD DevOps/CI kontekstis võimas tööriist. See aitab paremini mõista kvaliteedistandardeid, mida ja kuidas meeskond ehitab.
Arendusmeeskond peab otsustama, mida tähendab "Valmis". Nad peavad maha istuma ja koostama loetelu omadustest, mis peavad olema täidetud igas etapis, et seda loetaks täielikuks.
DoD muudab protsessi läbipaistvamaks ja muudab CI/CD juurutamise lihtsamaks, kui kõik meeskonnaliikmed sellest aru saavad ja vastastikku kokku lepivad.
Realistlike, selgelt määratletud eesmärkide puudumine
See on üks kõige sagedamini tsiteeritud nõuandeid, kuid seda tasub korrata. Mis tahes suuremas ettevõtmises, sealhulgas CI/CD või DevOps, edu saavutamiseks peate seadma realistlikud eesmärgid ja mõõtma jõudlust nende suhtes. Mida sa üritad CI/CD-ga saavutada? Kas see võimaldab parema kvaliteediga kiiremaid väljalaseid?
Kõik seatud eesmärgid peavad olema mitte ainult läbipaistvad ja realistlikud, vaid olema kooskõlas ka ettevõtte senise tegevusega. Näiteks kui sageli vajavad teie kliendid uusi plaastreid või versioone? Pole vaja protsesse üle koormata ja kiiremini vabastada, kui kasutajatele lisakasu pole.
Lisaks ei pea te alati rakendama nii CD-d kui ka CI-d. Näiteks võivad rangelt reguleeritud ettevõtted, nagu pangad ja meditsiinikliinikud, töötada ainult CI-ga.
CI on hea lähtepunkt igale DevOpsi juurutavale ettevõttele. Selle rakendamisel muutuvad ettevõtete lähenemisviisid tarkvara tarnimisele oluliselt. Kui CI on omandatud, võite mõelda kogu protsessi täiustamisele, levitamiskiiruse suurendamisele ja muudele muudatustele.
Paljude organisatsioonide jaoks piisab ainult CI-st ja CD tuleks rakendada ainult siis, kui see lisaväärtust loob.
Sobivate armatuurlaudade ja mõõdikute puudumine
Kui olete oma eesmärgid seadnud, saab arendusmeeskond luua KPI-de mõõtmiseks armatuurlaua. Enne selle väljatöötamist tasub hinnata parameetreid, mida jälgitakse.
Erinevad aruanded ja rakendused on kasulikud erinevatele meeskonnaliikmetele. Scrum Masterit huvitab rohkem staatus ja ulatus. Kuigi tippjuhtkonda võib huvitada spetsialistide läbipõlemismäär.
Mõned meeskonnad kasutavad CI/CD oleku hindamiseks ka punaste, kollaste ja roheliste indikaatoritega armatuurlaudu, et mõista, kas nad teevad kõik õigesti või on viga. Punane tähendab, et peate toimuvale tähelepanu pöörama.
Kui armatuurlauad pole aga standardiseeritud, võivad need olla eksitavad. Analüüsige, milliseid andmeid igaüks vajab, ja seejärel koostage standardiseeritud kirjeldus, mida need tähendavad. Uurige, mis on sidusrühmade jaoks mõttekam: graafika, tekst või numbrid.
Käsitsi testid puuduvad
Testimisautomaatika loob aluse heale CI/CD torujuhtmele. Kuid automatiseeritud testimine kõigis etappides ei tähenda, et te ei peaks käsitsi testima.
Tõhusa CI/CD konveieri loomiseks vajate ka käsitsi teste. Alati on testimisel mõned aspektid, mis nõuavad inimanalüüsi.
Tasub kaaluda käsitsi testimise integreerimist oma torusse. Kui mõne testjuhtumi käsitsi testimine on lõpule viidud, saate liikuda juurutamisetappi.
Ärge proovige teste parandada
Tõhus CI/CD konveier nõuab juurdepääsu õigetele tööriistadele, olgu selleks siis testihaldus või integreerimine ja pidev jälgimine.
Tugeva, kvaliteedile orienteeritud kultuuri loomise eesmärk on , jälgides klientidega suhtlemist pärast juurutamist ja jälgides täiustusi.
Siin on mõned praktilised näpunäited, mida saate hõlpsalt rakendada:
- Veenduge, et teie teste oleks lihtne kirjutada ja need oleksid piisavalt paindlikud, et mitte koodi ümberarvutamisel puruneda.
- Testimisprotsessi tuleks kaasata arendusmeeskonnad – vaadake loendit kasutajaprobleemidest ja taotlustest, mida on oluline CI-konveierite ajal testida.
- Teil ei pruugi olla täielikku testikatet, kuid veenduge alati, et UX-i ja kliendikogemuse jaoks olulisi vooge testitakse.
Viimane, kuid mitte vähem oluline punkt
Üleminek CI/CD-le toimub tavaliselt alt üles, kuid lõppkokkuvõttes on see ümberkujundamine, mis nõuab ettevõttelt juhtimisoskust, aega ja ressursse. CI/CD on ju oskuste, protsesside, tööriistade ja kultuurilise ümberkorraldamise kogum, selliseid muudatusi saab ellu viia vaid süstemaatiliselt.
Mida muud selle teema kohta lugeda:
- .
- .
- .
Allikas: www.habr.com