Se a vostra cumpagnia hè solu implementendu strumenti DevOps o CI / CD, pò esse utile per voi per cunniscenze cù l'errori più cumuni in modu chì ùn li ripetite micca è pisate u rake d'altru.
squadra traduttu l'articulu .
A vuluntà di cambià a cultura è i prucessi
Fighjendu u diagramma di u ciclu , hè chjaru chì in i pratichi DevOps, a prova hè un travagliu cuntinuu, una parte fundamentale di ogni implementazione individuale.
Diagramma di u Ciclu Infinitu DevOps
A prova è a garanzia di qualità durante u sviluppu è a consegna hè una parte essenziale di tuttu ciò chì i sviluppatori facenu. Questu hè bisognu di un cambiamentu di mentalità per include a prova in ogni attività.
A prova diventa parte di u travagliu di ogni ghjornu di ogni membru di a squadra. A transizione à a prova cuntinua ùn hè micca faciule, avete bisognu à esse preparatu per questu.
Mancanza di feedback
L'efficacità di DevOps dipende da un feedback constante. A migliione cuntinua ùn hè micca pussibule s'ellu ùn ci hè spaziu per a cullaburazione è a cumunicazione.
L'imprese chì ùn organizanu micca riunioni retrospettive trovanu difficiuli di implementà una cultura di feedback cuntinuu in CI / CD. E riunioni retrospettive sò tenute à a fine di ogni iterazione, induve i membri di u gruppu discutenu ciò chì hè andatu bè è ciò chì hè andatu male. E riunioni retrospettive sò u fundamentu di Scrum / Agile, ma sò ancu essenziali per DevOps.
Questu hè chì e riunioni retrospettive inculcanu l'abitudine di scambià feedback è opinioni. Unu di i mumenti più impurtanti à l'iniziu hè l'urganizazione di riunioni retro recurrenti in modu chì diventanu cumpresi è familiari à tutta a squadra.
Quandu si tratta di a qualità di u software, tutti i membri di a squadra sò rispunsevuli di mantene. Per esempiu, i sviluppatori ponu scrive teste di unità è ancu codice cun testabilità in mente, aiutendu à mitigà u risicu da u principiu.
Un modu faciule per riflette a percepzioni cambiante di a prova hè di chjamà i testatori micca QA ma testatore di software o ingegnere di qualità. Stu cambiamentu pò parè troppu simplice o ancu stupidu. Ma chjamà qualcunu un "specialista di assicuranza di qualità di software" dà l'idea sbagliata di quale hè rispunsevule per a qualità di u produttu. In pratiche Agile, CI / CD è DevOps, tutti sò rispunsevuli di a qualità di u software.
Un altru puntu impurtante hè di capisce ciò chì a qualità significa per a squadra sana è ognunu di i so membri, urganizazione, stakeholder.
Malcomprensione di a fine di a tappa
Se a qualità hè un prucessu cuntinuu è spartutu, hè necessariu una cunniscenza cumuna di a fine di una tappa. Cumu capisce chì a tappa hè finita ? Chì succede quandu una tappa hè marcata cum'è cumpletata nantu à una tavola Trello o un altru tavulinu kanban?
A determinazione di un passu cumpletu (DoD) hè un strumentu putente in u cuntestu di CD DevOps / CI. Aiuta à capisce megliu i normi di qualità di ciò chì è cumu si custruisce a squadra.
U squadra di sviluppu deve decide ciò chì significa "Fattu". Hanu bisognu à pusà è fà una lista di e caratteristiche chì deve esse scontru in ogni stadiu per pudè esse cunsideratu cumpletu.
DoD rende u prucessu più trasparente è facilita l'implementazione di CI / CD, s'ellu hè chjaru per tutti i membri di a squadra è cuncordatu mutualmente.
Mancanza di scopi realistichi, chjaramente definiti
Questu hè unu di i cunsiglii più spessu citati, ma vale a pena ripetiri. Perchè ogni impresa seria per riesce, cumpresa l'implementazione di CI/CD o DevOps, avete bisognu di stabilisce obiettivi realistichi è misurà u rendimentu contru à elli. Chì pruvate d'ottene cù CI/CD? Permette liberazioni più veloci cù una qualità megliu?
Ogni scopu stabilitu deve esse micca solu trasparenti è realistichi, ma ancu coherente cù l'attività attuale di a cumpagnia. Per esempiu, quantu spessu i vostri clienti necessitanu novi patch o versioni? Ùn ci hè micca bisognu di sopracarcà i prucessi è liberate più veloce s'ellu ùn ci hè micca un benefiziu supplementu per l'utilizatori.
Inoltre, ùn hè micca sempre bisognu di implementà CD è CI. Per esempiu, l'imprese altamente regulate cum'è i banche è e cliniche mediche ponu travaglià solu cù CI.
CI hè un bonu puntu di partenza per qualsiasi cumpagnia chì implementa DevOps. Quandu hè implementatu in una cumpagnia, l'avvicinamenti à a consegna di u software cambianu significativamente. Una volta CI hè maestru, pudete pensà à migliurà tuttu u prucessu, aumentendu a velocità di rollout è altri cambiamenti.
Per parechje urganisazione, un CI hè abbastanza, è u CD deve esse implementatu solu s'ellu aghjunghje valore.
Mancanza di dashboards è metriche pertinenti
Una volta chì avete stabilitu scopi, u squadra di sviluppu pò creà un dashboard per misurà i KPI. Prima di u so sviluppu, vale a pena evaluà i paràmetri chì saranu monitorati.
Diversi rapporti è applicazioni sò utili per i diversi membri di a squadra. I maestri Scrum sò più preoccupati di u statutu è di a portata. Mentre chì l'alta dirigenza pò esse interessatu à a rata di burnout di i specialisti.
Certi squadre utilizanu ancu dashboards cù indicatori rossi, gialli è verdi per valutà u statutu di CI / CD, per capisce s'ellu facenu tuttu bè o s'ellu hè accadutu un errore. Rossu significa chì avete bisognu di attentu à ciò chì succede.
Tuttavia, se i dashboards ùn sò micca standardizzati, ponu esse ingannevoli. Analizà ciò chì tutti anu bisognu di dati è poi creanu una descrizzione standardizzata di ciò chì significa. Scuprite ciò chì face più sensu per i vostri stakeholder: grafica, testu o numeri.
Mancanza di testi manuali
L'automatizazione di teste pone a basa per una bona pipeline CI/CD. Ma a prova automatizata in tutte e tappe ùn significa micca chì ùn deve micca fà una prova manuale.
Per custruisce un pipeline CI / CD efficiente, i testi manuali sò ancu necessarii. Ci saranu sempre certi aspetti di teste chì necessitanu analisi umane.
Vale a pena di cunsiderà l'integrazione di sforzi di teste manuali in u pipeline. Una volta chì a prova manuale di certi casi di prova hè cumpleta, pudete passà à a fase di implementazione.
Ùn pruvate micca di migliurà e teste
Un pipeline CI/CD efficace richiede l'accessu à l'arnesi ghjusti, ch'ella sia a gestione di teste o l'integrazione è u monitoraghju continuu.
Crià una cultura forte, orientata à a qualità hà u scopu di , monitorizà l'esperienza di u cliente dopu a implementazione, è seguite e migliure.
Eccu alcuni cunsiglii pratichi chì pudete facilmente implementà:
- Assicuratevi chì i testi sò faciuli di scrive è abbastanza flessibili per ùn rompe micca quandu u codice hè refactored.
- E squadre di sviluppu devenu esse incluse in u prucessu di teste - vede una lista di prublemi d'utilizatori è richieste chì sò impurtanti per pruvà durante i pipelines CI.
- Ùn pudete micca avè una copertura di prova completa, ma sempre assicuratevi chì i flussi chì sò impurtanti per l'UX è l'esperienza di u cliente sò pruvati.
Ultimu ma micca menu puntu
A transizione à CI / CD hè generalmente iniziata da u fondu, ma à a fine hè una trasfurmazioni chì esige implicazione di gestione, tempu è risorse da parte di a cumpagnia. Dopu tuttu, CI / CD hè un inseme di cumpetenze, prucessi, arnesi è ristrutturazione culturale, tali cambiamenti ponu esse implementati solu sistematicamente.
Chì altru à leghje nantu à u tema:
- .
- .
- .
Source: www.habr.com