Zure enpresak DevOps edo CI/CD tresnak aurkezten ari bazara, baliagarria izan daiteke akats ohikoenak ezagutzea, ez errepikatzeko eta beste inoren arrastoa zapaltzeko.
Team artikulua itzuli du .
Kultura eta prozesuak aldatzeko prest ez egotea
Diagrama ziklikoari erreparatuz gero , argi dago DevOps praktiketan probak etengabeko jarduera bat direla, inplementazio bakoitzaren oinarrizko zati bat.
DevOps Infinite Cycle Diagrama
Garatzaileek egiten duten guztiaren funtsezko zatiak dira garapenean eta entregan egindako probak eta kalitatea bermatzea. Horrek pentsamolde aldaketa bat eskatzen du probak zeregin guztietan sartzeko.
Probak taldekide bakoitzaren eguneroko lanaren parte bihurtzen dira. Etengabeko probarako trantsizioa ez da erraza, horretarako prestatuta egon behar duzu.
Iritzi falta
DevOps eraginkortasuna etengabeko feedbackaren araberakoa da. Etengabeko hobekuntza ezinezkoa da elkarlanerako eta komunikaziorako tarterik ez badago.
Atzera begirako bilerak antolatzen ez dituzten enpresei zaila egiten zaie CI/CDn etengabeko feedbackaren kultura ezartzea. Iterazio bakoitzaren amaieran atzera begirako bilerak egiten dira, eta taldekideek ondo eta gaizki joan dena eztabaidatzen dute. Atzera begirako bilerak dira Scrum/Agileren oinarria, baina DevOps-erako ere beharrezkoak dira.
Hau da, atzera begirako bilerek iritziak eta iritziak trukatzeko ohitura pizten dutelako. Hasierako puntu garrantzitsuenetako bat retro bilera errepikakorrak antolatzea da, talde osoarentzat ulergarriak eta ezagunak izan daitezen.
Softwarearen kalitateari dagokionez, taldekide guztiak arduratzen dira hura mantentzeaz. Esaterako, garatzaileek unitate-probak idatzi ditzakete eta kodea ere idatzi dezakete probagarritasuna kontuan hartuta, hasieratik arriskua murrizten lagunduz.
Testei buruzko pentsamoldearen aldaketa islatzeko modu erraz bat probatzaileei ez QA, baizik eta software probatzaile edo kalitate ingeniari deitzea da. Aldaketa hau sinpleegia edo are ergelegia dirudi. Baina norbaiti "softwarearen kalitatea bermatzeko pertsona" deitzeak ideia okerra ematen du produktuaren kalitatearen arduradunari buruz. Agile, CI/CD eta DevOps praktiketan, denak dira softwarearen kalitatearen erantzule.
Beste puntu garrantzitsu bat da ulertzea zer den kalitatea talde osoarentzat eta bere kide bakoitzarentzat, erakundearentzat eta interes-taldeentzat.
Etapa amaitzeari buruzko gaizki ulertzea
Kalitatea prozesu jarraitua eta orokorra bada, etapa osatzearen ulermen komuna behar da. Nola dakizu etapa bat noiz amaitu den? Zer gertatzen da urrats bat Trello edo beste Kanban taula batean amaituta bezala markatzen denean?
Definition of Done (DoD) CD DevOps/CI-ren testuinguruan tresna indartsua da. Taldea zer eta nola eraikitzen den kalitate-estandarrak hobeto ulertzen laguntzen du.
Garapen-taldeak erabaki behar du zer esan nahi duen "Egindakoa". Eseri eta etapa bakoitzean bete beharreko ezaugarrien zerrenda egin behar dute, osatutzat jotzeko.
DoD-k prozesua gardenagoa egiten du eta CI/CD ezartzea errazten du taldekide guztiek ulertzen badute eta elkarrekin adosten badute.
Helburu errealistak eta argi definituak ez izatea
Hau da gehien aipatzen den aholkuetako bat, baina errepikatu beharra dago. Edozein ahalegin handitan arrakasta izateko, CI/CD edo DevOps barne, helburu errealistak ezarri eta haien errendimendua neurtu behar duzu. Zer lortzen saiatzen ari zara CI/CDrekin? Horrek aukera ematen al du kaleratze azkarragoak kalitate hobearekin?
Ezarritako edozein helburu gardena eta errealista izateaz gain, enpresaren egungo jarduerekin koherentea izan behar da. Adibidez, zenbat aldiz behar dituzte zure bezeroek adabaki edo bertsio berriak? Ez dago prozesuak gainkargatu eta azkarrago askatu beharrik erabiltzaileentzat onura gehigarririk ez badago.
Gainera, ez dituzu beti CD eta CI inplementatu behar. Esaterako, oso araututako enpresek, hala nola, bankuek eta mediku klinikek, CIrekin soilik lan egin dezakete.
CI abiapuntu ona da DevOps inplementatzen duen edozein enpresarentzat. Inplementatzen denean, enpresek softwarea entregatzeko duten ikuspegia nabarmen aldatzen da. CI menperatzen denean, prozesu osoa hobetzea, inplementazioaren abiadura eta bestelako aldaketak handitzea pentsa dezakezu.
Erakunde askorentzat, CI bakarrik nahikoa da, eta CD balioa gehitzen badu soilik ezarri beharko litzateke.
Aginte-panel eta metrika egokien falta
Zure helburuak ezarri ondoren, garapen-taldeak panel bat sor dezake KPIak neurtzeko. Bere garapena baino lehen, komeni da kontrolatuko diren parametroak baloratzea.
Txosten eta aplikazio desberdinak taldekide ezberdinentzat erabilgarriak dira. Scrum Masterri gehiago interesatzen zaio egoera eta irismena. Goi-zuzendaritzak espezialisten burnout-tasan interesa izan dezakeen bitartean.
Zenbait taldek adierazle gorri, horia eta berdea duten aginte-panelak ere erabiltzen dituzte CI/CDren egoera ebaluatzeko, dena ondo egiten ari diren edo akatsen bat dagoen ulertzeko. Gorriz gertatzen ari denari kasu egin behar zaiola esan nahi du.
Hala ere, aginte-panelak estandarizatu ez badira, engainagarriak izan daitezke. Aztertu bakoitzak zer datu behar dituen, eta, gero, sortu zer esan nahi duenaren deskribapen estandarizatu bat. Aurki itzazu zer den zentzu handiagoa duten eragileentzat: grafikoak, testuak edo zenbakiak.
Eskuzko probarik ez
Proba automatizazioak CI/CD kanalizazio on baten oinarriak ezartzen ditu. Baina fase guztietan proba automatizatuak ez du esan nahi eskuzko probak egin behar ez dituzunik.
CI/CD kanalizazio eraginkorra eraikitzeko, eskuzko probak ere behar dituzu. Beti egongo dira probak giza analisia eskatzen duten alderdi batzuk.
Merezi du eskuzko proba-esfortzuak zure kanalizazioan integratzea. Test-kasu batzuen eskuzko probak amaitutakoan, inplementazio fasera pasa zaitezke.
Ez saiatu probak hobetzen
CI/CD kanalizazio eraginkor batek tresna egokietara sarbidea behar du, probak kudeatzea edo integrazioa eta etengabeko monitorizazioa izan.
Kalitatera zuzendutako kultura sendoa sortzea du helburu , inplementatu osteko bezeroen interakzioak monitorizatzea eta hobekuntzak jarraipena egitea.
Hona hemen erraz ezar ditzakezun aholku praktiko batzuk:
- Ziurtatu zure probak idazteko errazak direla eta nahikoa malguak direla kodea birfaktorizatu duzunean hausteko.
- Garapen-taldeak proba-prozesuan sartu behar dira. Ikusi CI kanalizazioetan probatzeko garrantzitsuak diren erabiltzaileen arazo eta eskaeren zerrenda.
- Baliteke proba-estaldura osoa ez izatea, baina beti ziurtatu UX eta bezeroen esperientziarako garrantzitsuak diren fluxuak probatzen direla.
Azken puntu garrantzitsua baina ez behintzat
CI/CDrako trantsizioa behetik gora egiten da normalean, baina azken finean, enpresaren lidergoa, denbora eta baliabideak eskatzen dituen eraldaketa da. Azken finean, CI/CD gaitasunen, prozesuen, tresnen eta kultur berregituraketa multzo bat da; aldaketa horiek modu sistematikoan baino ezin dira gauzatu.
Zer gehiago irakurri gaiari buruz:
- .
- .
- .
Iturria: www.habr.com