Se la tua azienda sta appena iniziando a implementare DevOps o strumenti CI/CD, potrebbe esserti utile conoscere gli errori più comuni per evitarli e non ripetere le esperienze negative degli altri.
Team ha tradotto l'articolo .
Mancanza di preparazione al cambiamento culturale e ai processi
Se osserviamo il diagramma ciclico , si può notare che nelle pratiche DevOps la fase di test è un lavoro continuo, una parte fondamentale di ogni singolo deployment.
Il diagramma ciclico infinito di DevOps
Il testing e la garanzia di qualità nel processo di sviluppo e consegna sono elementi imprescindibili di tutto ciò che fanno gli sviluppatori. Ciò richiede un cambiamento di mentalità per integrare il testing in ogni attività.
Il testing diventa parte delle attività quotidiane di ogni membro del team. La transizione a un testing continuo non avviene facilmente, è necessario essere pronti a questo.
Mancanza di feedback
L'efficacia del DevOps si basa su un feedback continuo. Il miglioramento continuo è impossibile se non c'è spazio per la collaborazione e la comunicazione.
Le aziende che non organizzano incontri di retrospettiva faticano a implementare una cultura di feedback continuo nel CI/CD. Gli incontri di retrospettiva si tengono alla fine di ogni iterazione, dove i membri del gruppo discutono cosa ha funzionato e cosa no. Gli incontri di retrospettiva sono fondamentali per Scrum/Agile, ma sono anche necessari per il DevOps.
Questo perché gli incontri di retrospettiva insegnano l'abitudine di scambiarsi feedback e opinioni. Uno dei punti più importanti all'inizio è l'organizzazione di incontri retrospettivi ripetuti, affinché diventino chiari e familiari per tutto il team.
Quando si tratta di qualità del software, tutti i membri del team sono responsabili del suo mantenimento. Ad esempio, gli sviluppatori possono scrivere test modulari e progettare il codice pensando alla testabilità, contribuendo così a ridurre i rischi fin dall’inizio.
Uno dei modi più semplici per riflettere il cambiamento delle percezioni sul testing è chiamare i tester non QA, ma tester di software o ingegnere della qualità. Questo cambiamento può sembrare troppo semplice o addirittura stupido. Ma se qualcuno viene definito "specialista nella garanzia della qualità del software", si dà una falsa impressione di chi è responsabile per la qualità del prodotto. Nelle pratiche Agile, CI/CD e DevOps, tutti sono responsabili della qualità del software.
Un altro punto importante è capire cosa significa qualità per l'intero team e per ciascun suo membro, l'organizzazione e gli stakeholder.
Comprensione errata della completezza della fase
Se la qualità è un processo continuo e condiviso, è necessaria una comprensione comune della completezza della fase. Come si fa a capire che una fase è completata? Cosa succede quando una fase è contrassegnata come completata sulla bacheca Trello o su un'altra bacheca Kanban?
La definizione della fase completata (DoD) è uno strumento potente nel contesto di CD DevOps/CI. Aiuta a comprendere meglio gli standard di qualità di ciò che e come costruisce il team.
Il team di sviluppo deve chiarire cosa significa "Pronto". Devono sedersi e stilare un elenco delle caratteristiche che devono essere soddisfatte in ogni fase affinché possa essere considerato completato.
Il DoD rende il processo più trasparente e facilita l'implementazione del CI/CD, purché sia compreso e concordato da tutti i membri del team.
Mancanza di obiettivi realistici e chiaramente definiti
Questo è uno dei consigli più citati, ma vale la pena ripeterlo. Per il successo di qualsiasi iniziativa significativa, compresa l'implementazione di CI/CD o DevOps, è necessario stabilire obiettivi realistici e misurare le prestazioni rispetto ad essi. Cosa stai cercando di raggiungere con il CI/CD? Permette di rilasciare più rapidamente con una qualità migliore?
Qualsiasi obiettivo stabilito deve essere non solo trasparente e realistico, ma anche allineato alle attuali attività dell'azienda. Ad esempio, con quale frequenza i tuoi clienti richiedono nuove correzioni o versioni? Non è necessario sovraccaricare i processi e rilasciare più rapidamente se non ci sono vantaggi aggiuntivi per gli utenti.
Inoltre, non è sempre necessario implementare sia il CI che il CD. Ad esempio, aziende con un alto grado di regolamentazione, come banche e cliniche mediche, possono operare solo con il CI.
Il CI è un buon punto di partenza per qualsiasi azienda che stia adottando il DevOps. La sua implementazione cambia significativamente gli approcci alla fornitura di software. Una volta che il CI è stato padroneggiato, si può considerare di migliorare l'intero processo, aumentando la velocità di rilascio e apportando altre modifiche.
Per molte organizzazioni, un solo CI è sufficiente, e il CD dovrebbe essere implementato solo se offre un valore aggiunto.
Mancanza di pannelli di monitoraggio e metriche adeguate
Una volta stabiliti gli obiettivi, il team di sviluppo può creare un pannello di monitoraggio per misurare i KPI. Prima della sua progettazione, vale la pena valutare i parametri che verranno monitorati.
Diversi report e applicazioni sono utili per diversi membri del team. Gli Scrum Master sono maggiormente interessati allo stato e alla copertura, mentre la dirigenza potrebbe essere più interessata alla velocità di burnout dei dipendenti.
Alcune squadre usano anche dashboard con indicatori rossi, gialli e verdi per valutare lo stato del CI/CD, per capire se stanno procedendo correttamente o se è emerso un errore. Il rosso indica che è necessario prestare attenzione a quanto sta accadendo.
Tuttavia, se i pannelli informativi non sono standardizzati, possono risultare fuorvianti. Analizzate quali dati sono necessari a tutti e create poi una descrizione standardizzata di cosa significano. Scoprite cosa ha più senso per gli stakeholder: grafici, testo o numeri.
Mancanza di test manuali
L'automazione dei test costituisce la base per un buon pipeline CI/CD. Ma l'automazione dei test in tutte le fasi non significa che non debbano essere eseguiti test manuali.
Per costruire un pipeline CI/CD efficace, sono necessari anche test manuali. Ci saranno sempre alcuni aspetti del testing che richiedono analisi da parte di un essere umano.
È utile considerare l'integrazione degli sforzi per il testing manuale nel pipeline. Una volta completati i test manuali di alcuni casi, è possibile passare alla fase di deployment.
Non cercare di migliorare i test
Un'efficace pipeline CI/CD richiede accesso agli strumenti necessari, che si tratti di gestione dei test o integrazione e monitoraggio continuo.
Creare una forte cultura orientata alla qualità è finalizzato a , monitorare l'interazione con i clienti dopo il deployment e tracciare i miglioramenti.
Ecco alcuni consigli pratici che puoi implementare facilmente:
- Assicurati che i test siano facili da scrivere e sufficientemente flessibili da non rompersi durante il refactoring del codice.
- I team di sviluppo dovrebbero essere coinvolti nel processo di test: vedere l'elenco dei problemi e delle richieste degli utenti che sono importanti per i controlli durante le pipeline CI.
- Potresti non avere una copertura completa dei test, ma assicurati sempre che i flussi critici per l'UX e l'interazione con i clienti siano testati.
Ultimo, ma non meno importante
La transizione verso il CI/CD di solito inizia dal basso, ma alla fine si tratta di una trasformazione che richiede il coinvolgimento della direzione, oltre a un investimento di tempo e risorse da parte dell'azienda. Infatti, il CI/CD implica un insieme di competenze, processi, strumenti e un cambiamento culturale; tali modifiche possono essere implementate solo in modo sistematico.
Ulteriori letture sull'argomento:
- .
- .
- .
Fonte: habr.com
