Se la tua azienda sta solo implementando strumenti DevOps o CI/CD, potrebbe essere utile familiarizzare con gli errori più comuni in modo da non ripeterli e calpestare il rastrello di qualcun altro.
Squadra tradotto l'articolo .
Riluttanza a cambiare cultura e processi
Guardando il diagramma del ciclo , è chiaro che nelle pratiche DevOps il testing è un lavoro continuo, una parte fondamentale di ogni singolo deployment.
Diagramma ciclo infinito DevOps
I test e la garanzia della qualità durante lo sviluppo e la consegna sono una parte essenziale di tutto ciò che fanno gli sviluppatori. Ciò richiede un cambiamento di mentalità per includere i test in ogni attività.
I test diventano parte del lavoro quotidiano di ogni membro del team. Il passaggio ai test continui non è facile, devi essere preparato per questo.
Mancanza di feedback
L'efficacia di DevOps dipende da un feedback costante. Il miglioramento continuo non è possibile se non c'è spazio per la collaborazione e la comunicazione.
Le aziende che non organizzano riunioni retrospettive trovano difficile implementare una cultura del feedback continuo in CI/CD. Alla fine di ogni iterazione si tengono incontri retrospettivi, in cui i membri del gruppo discutono cosa è andato bene e cosa è andato storto. Le riunioni retrospettive sono la base di Scrum/Agile, ma sono essenziali anche per DevOps.
Questo perché gli incontri retrospettivi instillano l'abitudine di scambiarsi feedback e opinioni. Uno dei momenti più importanti all'inizio è l'organizzazione di riunioni ricorrenti in modo che diventino comprensibili e familiari a tutto il team.
Quando si tratta di qualità del software, tutti i membri del team sono responsabili della sua manutenzione. Ad esempio, gli sviluppatori possono scrivere test unitari e codice tenendo presente la testabilità, contribuendo a mitigare il rischio fin dall'inizio.
Un modo semplice per riflettere le mutevoli percezioni dei test è chiamare i tester non QA ma tester del software o ingegnere della qualità. Questo cambiamento può sembrare troppo semplice o addirittura stupido. Ma chiamare qualcuno "specialista della garanzia della qualità del software" dà un'idea sbagliata di chi è responsabile della 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 ciascuno dei suoi membri, organizzazione, stakeholder.
Incomprensione del completamento della fase
Se la qualità è un processo continuo e condiviso, è necessaria una comprensione comune del completamento di una fase. Come capire che il palco è finito? Cosa succede quando una pietra miliare viene contrassegnata come completata su una bacheca Trello o su un'altra bacheca kanban?
La determinazione di una pietra miliare completata (DoD) è uno strumento potente nel contesto di CD DevOps/CI. Aiuta a comprendere meglio gli standard di qualità di cosa e come costruisce il team.
Il team di sviluppo deve decidere cosa significa "Fatto". Devono sedersi e fare un elenco delle caratteristiche che devono essere soddisfatte in ogni fase in modo che possa essere considerato completo.
DoD rende il processo più trasparente e facilita l'implementazione di CI/CD, se è chiaro a tutti i membri del team e concordato di comune accordo.
Mancanza di obiettivi realistici e chiaramente definiti
Questo è uno dei suggerimenti più citati, ma vale la pena ripeterlo. Affinché qualsiasi impresa seria abbia successo, inclusa l'implementazione di CI/CD o DevOps, è necessario stabilire obiettivi realistici e misurare le prestazioni rispetto a tali obiettivi. Cosa stai cercando di ottenere con CI/CD? Permette rilasci più veloci con una migliore qualità?
Qualsiasi obiettivo fissato dovrebbe essere non solo trasparente e realistico, ma anche coerente con le attuali attività dell'azienda. Ad esempio, con quale frequenza i tuoi clienti necessitano di nuove patch o versioni? Non è necessario sovraccaricare i processi e rilasciare più velocemente se non ci sono ulteriori vantaggi per gli utenti.
Inoltre, non è sempre necessario implementare sia CD che CI. Ad esempio, aziende altamente regolamentate come banche e cliniche mediche possono lavorare solo con CI.
CI è un buon punto di partenza per qualsiasi azienda che implementa DevOps. Quando viene implementato in un'azienda, gli approcci alla consegna del software cambiano in modo significativo. Una volta padroneggiata la CI, puoi pensare a migliorare l'intero processo, aumentare la velocità di implementazione e altre modifiche.
Per molte organizzazioni, un CI è sufficiente e il CD dovrebbe essere implementato solo se aggiunge valore.
Mancanza di dashboard e metriche pertinenti
Una volta fissati gli obiettivi, il team di sviluppo può creare una dashboard per misurare i KPI. Prima del suo sviluppo, vale la pena valutare i parametri che verranno monitorati.
Diversi report e applicazioni sono utili per diversi membri del team. Gli Scrum Master sono più interessati allo status e alla portata. Mentre l'alta dirigenza potrebbe essere interessata al tasso di esaurimento degli specialisti.
Alcuni team utilizzano anche dashboard con indicatori rossi, gialli e verdi per valutare lo stato di CI/CD, per capire se stanno facendo tutto bene o se si è verificato un errore. Il rosso significa che devi prestare attenzione a ciò che sta accadendo.
Tuttavia, se i dashboard non sono standardizzati, possono essere fuorvianti. Analizza i dati di cui tutti hanno bisogno e poi crea una descrizione standardizzata del loro significato. Scopri cosa ha più senso per i tuoi stakeholder: grafica, testo o numeri.
Mancanza di test manuali
L'automazione dei test pone le basi per una buona pipeline CI/CD. Ma i test automatizzati in tutte le fasi non significano che non dovresti eseguire test manuali.
Per creare una pipeline CI/CD efficiente, sono necessari anche test manuali. Ci saranno sempre alcuni aspetti dei test che richiedono un'analisi umana.
Vale la pena considerare l'integrazione degli sforzi di test manuali nella pipeline. Una volta completata la verifica manuale di alcuni casi di test, si può passare alla fase di deployment.
Non cercare di migliorare i test
Una pipeline CI/CD efficace richiede l'accesso agli strumenti giusti, che si tratti di gestione dei test o integrazione e monitoraggio continuo.
Creare una cultura forte e orientata alla qualità mira a , monitorare l'esperienza del cliente dopo l'implementazione e tenere traccia dei miglioramenti.
Ecco alcuni consigli pratici che puoi facilmente implementare:
- Assicurati che i test siano facili da scrivere e abbastanza flessibili da non rompersi quando il codice viene rifattorizzato.
- I team di sviluppo devono essere inclusi nel processo di test: vedere un elenco di problemi e richieste degli utenti che è importante testare durante le pipeline CI.
- Potresti non avere una copertura completa del test, ma assicurati sempre che i flussi importanti per l'UX e l'esperienza del cliente siano testati.
Ultimo ma non meno importante punto
Il passaggio a CI/CD è solitamente avviato dal basso verso l'alto, ma alla fine è una trasformazione che richiede il coinvolgimento del management, tempo e risorse da parte dell'azienda. Dopotutto, CI / CD è un insieme di abilità, processi, strumenti e ristrutturazioni culturali, tali cambiamenti possono essere implementati solo sistematicamente.
Cos'altro leggere sull'argomento:
- .
- .
- .
Fonte: habr.com