As jou maatskappy net DevOps- of CI/CD-nutsmiddels bekendstel, kan dit nuttig wees vir jou om vertroud te raak met die mees algemene foute om dit nie te herhaal nie en nie op iemand anders se hark te trap nie.
Span het die artikel vertaal .
Onvoorbereidheid om kultuur en prosesse te verander
As jy na die sikliese diagram kyk , is dit duidelik dat in DevOps-praktyke toetsing 'n deurlopende aktiwiteit is, 'n fundamentele deel van elke enkele ontplooiing.
DevOps Oneindige siklus grafiek
Toetsing en gehalteversekering tydens ontwikkeling en aflewering is 'n noodsaaklike deel van alles wat ontwikkelaars doen. Dit vereis 'n ingesteldheidsverskuiwing om toetsing by elke taak in te sluit.
Toetsing word deel van die daaglikse werk van elke spanlid. Die oorgang na konstante toetsing is nie maklik nie, jy moet daarop voorbereid wees.
Gebrek aan terugvoer
DevOps-effektiwiteit hang af van konstante terugvoer. Deurlopende verbetering is onmoontlik as daar nie ruimte vir samewerking en kommunikasie is nie.
Maatskappye wat nie terugwerkende vergaderings organiseer nie, vind dit moeilik om 'n kultuur van deurlopende terugvoer in CI/CD te implementeer. Retrospektiewe vergaderings word aan die einde van elke iterasie gehou, waartydens spanlede bespreek wat goed en wat swak gegaan het. Retrospektiewe vergaderings is die grondslag van Scrum/Agile, maar dit is ook nodig vir DevOps.
Dit is omdat retrospektiewe vergaderings die gewoonte aanleer om terugvoer en menings uit te ruil. Een van die belangrikste punte aan die begin is om herhalende retro-vergaderings te organiseer sodat dit verstaanbaar en bekend word vir die hele span.
Wat sagtewaregehalte betref, is alle spanlede daarvoor verantwoordelik om dit in stand te hou. Ontwikkelaars kan byvoorbeeld eenheidstoetse skryf en ook kode skryf met toetsbaarheid in gedagte, wat van die begin af risiko help verminder.
Een eenvoudige manier om die verandering in denke oor toetsing te weerspieël, is om toetsers nie QA te noem nie, maar sagtewaretoetser of kwaliteitingenieur. Hierdie verandering lyk dalk te eenvoudig of selfs dom. Maar om iemand 'n "sagteware kwaliteitversekeringspersoon" te noem, gee die verkeerde idee oor wie verantwoordelik is vir die kwaliteit van die produk. In Agile-, CI/CD- en DevOps-praktyke is almal verantwoordelik vir sagtewarekwaliteit.
Nog 'n belangrike punt is om te verstaan wat kwaliteit vir die hele span en elkeen van sy lede, die organisasie en belanghebbendes beteken.
Misverstand van stadiumvoltooiing
As kwaliteit 'n deurlopende en algemene proses is, is 'n gemeenskaplike begrip van stadiumvoltooiing nodig. Hoe weet jy wanneer 'n stadium verby is? Wat gebeur wanneer 'n stap as voltooi op 'n Trello- of ander Kanban-bord gemerk word?
Definisie van Klaar (DoD) is 'n kragtige instrument in die konteks van CD DevOps/CI. Dit help om die kwaliteitstandaarde van wat en hoe die span bou, beter te verstaan.
Die ontwikkelingspan moet besluit wat "Klaar" beteken. Hulle moet gaan sit en 'n lys maak van eienskappe waaraan in elke stadium voldoen moet word om dit as volledig beskou te kan word.
DoD maak die proses meer deursigtig en maak dit makliker om CI/CD te implementeer as dit deur alle spanlede verstaan word en onderling ooreengekom word.
Gebrek aan realistiese, duidelik gedefinieerde doelwitte
Dit is een van die raad wat die meeste aangehaal word, maar dit moet herhaal word. Om sukses te behaal in enige groot poging, insluitend CI/CD of DevOps, moet jy realistiese doelwitte stel en prestasie daarteen meet. Wat probeer jy bereik met CI/CD? Laat dit vinniger vrystellings met beter gehalte toe?
Enige doelwitte wat gestel word, moet nie net deursigtig en realisties wees nie, maar moet ook ooreenstem met die huidige aktiwiteite van die maatskappy. Byvoorbeeld, hoe gereeld het jou kliënte nuwe pleisters of weergawes nodig? Dit is nie nodig om prosesse te oorlaai en vinniger vry te stel as daar geen bykomende voordeel vir gebruikers is nie.
Daarbenewens hoef jy nie altyd beide CD en CI te implementeer nie. Byvoorbeeld, hoogs gereguleerde maatskappye soos banke en mediese klinieke mag slegs met CI werk.
CI dien as 'n goeie beginpunt vir enige maatskappy wat DevOps implementeer. Wanneer dit geïmplementeer word, verander maatskappye se benaderings tot sagteware-lewering aansienlik. Sodra CI bemeester is, kan jy daaraan dink om die hele proses te verbeter, die uitrolspoed en ander veranderinge te verhoog.
Vir baie organisasies is GI alleen voldoende, en CD moet slegs geïmplementeer word as dit waarde toevoeg.
Gebrek aan toepaslike dashboards en maatstawwe
Sodra jy jou doelwitte gestel het, kan die ontwikkelingspan 'n dashboard skep om KPI's te meet. Voordat dit ontwikkel word, is dit die moeite werd om die parameters wat gemonitor sal word, te assesseer.
Verskillende verslae en toepassings is nuttig vir verskillende spanlede. Die Scrum Master stel meer belang in status en bereik. Terwyl senior bestuur dalk belangstel in die uitbrandingsyfer van spesialiste.
Sommige spanne gebruik ook dashboards met rooi, geel en groen aanwysers om die status van CI/CD te assesseer om te verstaan of hulle alles reg doen en of daar 'n fout is. Rooi beteken jy moet aandag gee aan wat gebeur.
As dashboards egter nie gestandaardiseer is nie, kan dit misleidend wees. Ontleed watter data almal nodig het, en skep dan 'n gestandaardiseerde beskrywing van wat dit beteken. Vind uit wat meer sin maak vir belanghebbendes: grafika, teks of syfers.
Geen handtoetse nie
Toetsoutomatisering lê die grondslag vir 'n goeie CI/CD-pyplyn. Maar outomatiese toetsing in alle stadiums beteken nie dat u nie handmatige toetsing moet uitvoer nie.
Om 'n effektiewe CI/CD-pyplyn te bou, benodig jy ook handtoetse. Daar sal altyd sekere aspekte van toetsing wees wat menslike ontleding vereis.
Dit is die moeite werd om te oorweeg om handmatige toetspogings in u pyplyn te integreer. Sodra die handmatige toetsing van sommige toetsgevalle voltooi is, kan jy aanbeweeg na die ontplooiingsfase.
Moenie toetse probeer verbeter nie
’n Effektiewe CI/CD-pyplyn vereis toegang tot die regte gereedskap, of dit nou toetsbestuur of integrasie en deurlopende monitering is.
Die skep van 'n sterk, kwaliteit-georiënteerde kultuur het ten doel om , monitering van klante-interaksies na-ontplooiing en die dop van verbeterings.
Hier is 'n paar praktiese wenke wat jy maklik kan implementeer:
- Maak seker dat jou toetse maklik is om te skryf en buigsaam genoeg is om nie te breek wanneer jy die kode herfaktoreer nie.
- Ontwikkelingspanne moet by die toetsproses ingesluit word - sien 'n lys van gebruikerskwessies en -versoeke wat belangrik is om tydens CI-pypleidings te toets.
- Jy het dalk nie volle toetsdekking nie, maar maak altyd seker dat vloeie wat belangrik is vir UX en klante-ervaring getoets word.
Laaste maar nie die minste belangrike punt nie
Die oorgang na CI/CD word gewoonlik van onder af gedryf, maar uiteindelik is dit 'n transformasie wat leierskap-inkoop, tyd en hulpbronne van die maatskappy vereis. GI/CD is immers 'n stel vaardighede, prosesse, gereedskap en kulturele herstrukturering; sulke veranderinge kan slegs sistematies geïmplementeer word.
Wat anders om te lees oor die onderwerp:
- .
- .
- .
Bron: will.com