Se la tua azienda sta appena introducendo DevOps o strumenti CI/CD, potrebbe esserti utile conoscere gli errori più comuni per evitarli e non ripetere le sgambate altrui.
Team ha tradotto l'articolo .
Inadeguatezza a cambiare cultura e processi
Guardando il diagramma ciclico , si può notare che nelle pratiche DevOps il testing è un'attività continua, una parte fondamentale di ogni singolo rilascio.
Diagramma ciclico infinito di DevOps
Il testing e il garantire la qualità durante il processo di sviluppo e consegna sono parti essenziali di tutto ciò che fanno gli sviluppatori. Ciò richiede un cambiamento di mentalità che integri il testing in ogni compito.
Il testing diventa parte del lavoro quotidiano di ciascun membro del team. Il passaggio a un testing continuo non è facile e richiede preparazione.
Mancanza di feedback
L'efficacia di DevOps dipende da un feedback costante. Il miglioramento continuo è impossibile se non c'è spazio per la collaborazione e la comunicazione.
Per le aziende che non organizzano incontri retrospettivi, è difficile instaurare una cultura di feedback continuo in CI/CD. Gli incontri retrospettivi si tengono alla fine di ogni iterazione, durante i quali i membri del team discutono di ciò che è andato bene e di ciò che è andato male. Gli incontri retrospettivi sono fondamentali per Scrum/Agile, ma sono anche necessari per DevOps.
Ciò è dovuto al fatto che gli incontri retrospettivi promuovono l'abitudine di scambiarsi feedback e opinioni. Uno degli aspetti più importanti all'inizio è organizzare incontri retrospettivi ripetuti, affinché diventino chiari e abituali per tutto il team.
Quando si tratta della qualità del software, tutti i membri del team sono responsabili del suo mantenimento. Ad esempio, gli sviluppatori possono scrivere test modulari e scrivere codice tenendo conto della testabilità, contribuendo a ridurre i rischi fin dall'inizio.
Uno dei modi più semplici per riflettere il cambiamento delle percezioni sul testing è chiamare i testatori non QA, ma tester software o ingegneri della qualità. Questo cambiamento potrebbe sembrare troppo semplice o addirittura stupido. Ma se qualcuno viene chiamato "specialista nella garanzia della qualità del software", si crea una falsa impressione su chi è responsabile della qualità del prodotto. Nelle pratiche Agile, CI/CD e DevOps, tutti sono responsabili della qualità del software.
Un altro aspetto importante è capire cosa significa qualità per l'intero team e per ciascun suo membro, organizzazione e stakeholder.
Incomprensione della completezza della fase
Se la qualità è un processo continuo e condiviso, è necessaria una comprensione comune della completezza della fase. Come si fa a sapere quando una fase è completata? Cosa succede quando una fase è contrassegnata come completata nella bacheca di Trello o in un'altra bacheca Kanban?
La definizione della fase completata (DoD) è uno strumento potente nel contesto del CD DevOps/CI. Aiuta a comprendere meglio gli standard di qualità di ciò che e come costruisce il team.
Il team di sviluppatori deve decidere cosa significa "Fatto". Devono sedersi e redigere un elenco di caratteristiche che devono essere soddisfatte in ogni fase affinché possa essere considerata completata.
Il DoD rende il processo più trasparente e facilita l'implementazione del CI/CD, se è chiaro a tutti i membri del team e reciprocamente concordato.
Mancanza di obiettivi realistici e ben definiti
Questo è uno dei consigli più citati, ma vale la pena ripetere. Per il successo di qualsiasi iniziativa seria, 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 CI/CD? Permette di rilasciare più rapidamente con una qualità migliore?
Qualsiasi obiettivo stabilito deve essere non solo trasparente e realistico, ma anche allineato con le attività attuali dell'azienda. Ad esempio, con quale frequenza i tuoi clienti hanno bisogno di nuove correzioni o versioni? Non c'è bisogno di sovraccaricare i processi e rilasciare versioni più velocemente, se non ci sono vantaggi addizionali per gli utenti.
Inoltre, non è sempre necessario implementare sia CD che CI. Ad esempio, le aziende con un alto grado di regolamentazione, come le banche e le cliniche mediche, possono lavorare solo con CI.
CI è un buon punto di partenza per qualsiasi azienda che sta implementando DevOps. Con l'adozione del CI, gli approcci alla consegna del software cambiano significativamente. Una volta che il CI è stato padroneggiato, si può pensare a migliorare l'intero processo, aumentando la velocità di distribuzione e apportando altre modifiche.
Per molte organizzazioni, un solo CI è sufficiente, e il CD dovrebbe essere implementato solo se porta un valore aggiunto.
Mancanza di cruscotti e metriche appropriate
Una volta stabiliti gli obiettivi, il team di sviluppo può creare un cruscotto per misurare i KPI. Prima della sua progettazione, è opportuno valutare i parametri che saranno monitorati.
Diversi report e applicazioni risultano utili per i diversi membri del team. I Scrum Master sono più interessati allo stato e alla copertura. Mentre la direzione superiore potrebbe essere interessata alla velocità di esaurimento delle risorse.
Alcuni team utilizzano anche cruscotti con indicatori rossi, gialli e verdi per valutare lo stato del CI/CD, in modo da capire se stanno facendo tutto correttamente o se si è verificato un errore. Il rosso indica che è necessario prestare attenzione a quanto sta accadendo.
Tuttavia, se i cruscotti non sono standardizzati, possono creare confusione. Analizza quali dati sono necessari a tutti e poi crea una descrizione standardizzata di ciò che significano. Scopri cosa ha più senso per le parti interessate: grafici, testo o numeri.
Mancanza di test manuali
L'automazione dei test pone le basi per un buon pipeline CI/CD. Ma avere test automatizzati in tutte le fasi non significa che non si debbano eseguire test manuali.
Per costruire un pipeline CI/CD efficace, sono necessari anche test manuali. Ci saranno sempre alcuni aspetti del testing che richiedono l'analisi di un umano.
Vale la pena considerare l'integrazione degli sforzi di testing manuale nel pipeline. Una volta completati i test manuali di alcuni casi di test, puoi passare alla fase di distribuzione.
Non cercare di migliorare i test
Un'efficace pipeline CI/CD richiede accesso agli strumenti necessari, siano essi la gestione dei test o l'integrazione e il monitoraggio continuo.
Creare una cultura forte, orientata alla qualità, mira a , monitorare le interazioni dei clienti dopo il deployment e tracciare i miglioramenti.
Ecco alcuni consigli pratici che puoi facilmente implementare:
- Assicurati che i test siano facili da scrivere e abbastanza flessibili da non rompersi durante il refactoring del codice.
- I team di sviluppo devono essere coinvolti nel processo di testing: devono vedere l'elenco dei problemi e delle richieste degli utenti che sono importanti da verificare durante le pipeline CI.
- Potresti non avere una copertura totale dei test, ma assicurati sempre che i flussi importanti per l'UX e l'interazione con i clienti siano testati.
Ultimo, ma non meno importante
La transizione a CI/CD è solitamente avviata dal basso verso l'alto, ma, alla fine, si tratta di una trasformazione che richiede il coinvolgimento della direzione, tempo e risorse da parte dell'azienda. Infatti, CI/CD è un insieme di competenze, processi, strumenti e un cambiamento culturale che può essere implementato solo in modo sistemico.
Cosa leggere ancora sull'argomento:
- .
- .
- .
Fonte: habr.com
