5 insidie ​​comuni di CI / CD e come evitarle

Devops può essere uno dei termini più confusi nello sviluppo del software, ma la maggior parte di noi concorda sul fatto che cinque attività rendono devops quello che è: integrazione continua, distribuzione continua, infrastruttura cloud, automazione dei test e gestione della configurazione. Se fai queste cinque cose, fai devops. Chiaramente, tutti e cinque sono importanti per avere ragione, ma è fin troppo facile sbagliare. In particolare, l'integrazione continua e la consegna continua (CI / CD) possono essere le mosse devops più difficili da padroneggiare.

L'integrazione continua (CI) è un processo in cui sviluppatori e tester convalidano in modo collaborativo il nuovo codice. Tradizionalmente, gli sviluppatori scrivevano codice e lo integravano una volta al mese per i test. Era inefficiente: un errore nel codice di quattro settimane fa poteva costringere gli sviluppatori a rivedere il codice scritto una settimana fa. Per superare questo problema, CI dipende dall'automazione per integrare e testare il codice continuamente. I team Scrum utilizzano il codice di commit CI almeno quotidianamente, mentre la maggior parte di loro esegue il commit del codice per ogni modifica introdotta.

La consegna continua (CD) è il processo di creazione continua di artefatti rilasciabili. Alcune aziende rilasciano agli utenti una o anche più volte al giorno, mentre altre rilasciano il software a un ritmo più lento per ragioni di mercato. In ogni caso, la capacità di rilascio viene testata continuamente. L' implementazione continua è possibile grazie agli ambienti cloud. I server sono configurati in modo tale da poter essere distribuiti alla produzione senza arrestare e aggiornare manualmente i server.

Pertanto, CI / CD è un processo per lo sviluppo, il test e la consegna continui di nuovo codice. Alcune aziende come Facebook e Netflix utilizzano CI / CD per completare 10 o più versioni a settimana. Altre aziende hanno difficoltà a raggiungere quel ritmo perché soccombono a una o più delle cinque insidie ​​di cui parlerò in seguito.

Insidia CI / CD n. 1: automatizzare prima i processi sbagliati

Questa trappola tende a colpire le organizzazioni che stanno passando dallo sviluppo a cascata al devops. Le nuove organizzazioni hanno il vantaggio di implementare CI / CD da zero. Le aziende esistenti devono passare gradualmente dallo sviluppo manuale a quello altamente automatizzato. La transizione completa può richiedere diversi mesi, il che significa che devi essere iterativo nel modo in cui adotti CI / CD.

Quando chiedi: "È necessario automatizzare ora?" eseguire la seguente lista di controllo:

  1. Con quale frequenza viene ripetuto il processo o lo scenario?
  2. Quanto dura il processo?
  3. Quali persone e quali dipendenze dalle risorse sono coinvolte nel processo? Stanno causando ritardi in CI / CD?
  4. Il processo è soggetto a errori se non è automatizzato?
  5. Qual è l'urgenza di automatizzare il processo?

Utilizzando questo elenco di controllo, è possibile assegnare la priorità ai passaggi in un'implementazione CI / CD. Innanzitutto, automatizza il processo di compilazione del codice. Idealmente, integrerai il codice più volte al giorno (1). Manualmente, il processo richiede da pochi minuti a un paio d'ore (2). Ciò blocca l'output fino a quando il compilatore non termina l'attività (3). È anche suscettibile di errore umano (4) e poiché CI / CD è un sogno irrealizzabile senza integrazione automatizzata, questo è urgente (5).

Possiamo eseguire la stessa lista di controllo durante i test. Durante la transizione a CI / CD, potresti chiederti: dobbiamo prima automatizzare i test funzionali o i test dell'interfaccia utente? Entrambi verranno ripetuti almeno una volta al giorno (1). Entrambi possono richiedere da due a tre ore per un'applicazione di medie dimensioni (2). Ma coinvolgono più dipendenze (3). Se si automatizzano i test funzionali, potrebbe non essere necessario aggiornare lo script di automazione così frequentemente. L'interfaccia utente, d'altra parte, cambia spesso e quindi richiede frequenti modifiche allo script. Sebbene entrambi siano soggetti a errori (4), dovresti dare la priorità ai test funzionali prima del test dell'interfaccia utente per utilizzare al meglio le tue risorse (5).

Facciamolo ancora una volta con il processo di configurazione degli ambienti. Questo scenario si ripete frequentemente solo se sei impegnato nelle assunzioni o stai vivendo un pesante churn (1). È un processo piuttosto dispendioso in termini di tempo che può richiedere diverse ore se non giorni (2). I nuovi membri del team non possono fare nulla di utile senza ambienti, quindi chiaramente c'è una dipendenza e un ritardo (3). Non direi che il processo è soggetto a errori (4), quindi è ancora urgente (5)? Mi propongo di sì, ma darei comunque la priorità all'integrazione e al test funzionale prima.

Non esiste l'automazione eccessiva. Se avessi risorse illimitate, automatizzeresti tutto il possibile. Detto questo, non è possibile ottenere un'automazione totale dei test. A volte puoi suddividere le attività in segmenti più piccoli e automatizzarle in patch. A volte dovresti semplicemente documentare il processo in dettaglio ed eseguirlo manualmente.

Insidia CI / CD n. 2: confondere la distribuzione continua per la consegna continua

La distribuzione continua è il concetto secondo cui ogni modifica apportata alla base di codice verrà distribuita quasi immediatamente alla produzione se i risultati della pipeline hanno esito positivo. Questo è terrificante per la maggior parte delle organizzazioni perché i rapidi cambiamenti dei prodotti possono spaventare gli utenti.

Le aziende credono che se non praticano la distribuzione continua, non stanno facendo CD. Non riescono a distinguere tra distribuzione continua e distribuzione continua.

La consegna continua è il concetto che ogni modifica alla base di codice passa attraverso la pipeline fino al punto di distribuzione in ambienti non di produzione. Il team trova e risolve i problemi immediatamente, non più tardi quando prevede di rilasciare la base di codice.

La base del codice è sempre a un livello di qualità sicuro per il rilascio. Quando rilasciare la base di codice alla produzione è una decisione aziendale.

Mentre la distribuzione continua sconvolge la maggior parte delle organizzazioni, la consegna continua risuona con loro. La distribuzione continua offre loro il controllo sull'implementazione del prodotto, sulla funzionalità e sui fattori di rischio. C'è tempo per i test alpha, per i clienti beta, per i primi utenti e così via.

Insidia n. 3 CI / CD: mancanza di dashboard e metriche significative

Nelle implementazioni CI / CD, il team di Scrum può creare un dashboard prima che i membri sappiano cosa devono monitorare. Di conseguenza, il team è vittima di un errore logico: "Queste sono le metriche che abbiamo, quindi devono essere importanti". Esegui invece una valutazione progressiva prima di progettare un dashboard.

Diversi membri di un'organizzazione IT e persino vari membri di un team di Scrum hanno priorità diverse. Ad esempio, le persone in un centro operativo di rete (NOC) amano gli indicatori rossi, gialli e verdi. Tali dashboard semaforiche consentono al personale NOC di distinguere i problemi senza leggere un testo denso o mettere a dura prova le proprie capacità analitiche. I semafori aiutano a rendere gestibili centinaia di server.

Potresti essere tentato di utilizzare un cruscotto a semaforo anche per CI / CD. Green, siamo sulla buona strada. Giallo, siamo fuori strada, ma abbiamo un piano per affrontarlo. Rosso, siamo fuori strada e probabilmente dovremo cambiare i nostri obiettivi.

Quella dashboard è probabilmente utile per uno scrum master, ma per quanto riguarda il VP dello sviluppo o il CTO? Se un team di mischia ha 350 ore di lavoro davanti per uno sprint di due settimane e i suoi 10 membri sono responsabili di 35 ore ciascuno, riceveranno un numero corrispondente di story point. Il management superiore potrebbe essere meno interessato allo stato degli story point e più curioso del tasso di "burn-down": la velocità di completamento dell'attività. I membri del team portano i loro carichi? Quanto velocemente? Stanno migliorando nel tempo?

Sfortunatamente, i tassi di burndown potrebbero essere fuorvianti se i vari stakeholder non capiscono le abitudini concordate dal team di Scrum. Alcune squadre bruciano punti presto mentre vanno. Altri aspettano fino alla fine dello sprint per bruciare i punti aperti. Il dashboard dovrebbe tenerne conto.      

Se puoi valutare quali dati vogliono tutti e stabilire una narrativa standard per il significato di tali dati, puoi progettare una dashboard utile. Ma non ossessionarti per la sostanza a scapito dell'aspetto. Chiedi come le parti interessate vogliono che appaia. I grafici, il testo oi numeri sarebbero i migliori?

Queste sono le considerazioni su cui indagare in una valutazione progressiva. Illustrano quanto sia complicato creare un utile dashboard CI / CD e rendere tutti felici. Troppo spesso, il membro del team più esplicito dirotta il processo e gli altri si sentono frustrati dal fatto che il dashboard soddisfi solo le preferenze di una persona. Ascolta tutti.  

Insidia CI / CD n. 4: mancanza di coordinamento tra integrazione continua e fornitura continua

Questa trappola ci riporta alla nostra definizione consensuale di devops, che sostiene che l'integrazione continua e la consegna continua sono due elementi diversi. CI alimenta il CD. L'implementazione di una pipeline di integrazione continua decente e un sistema di distribuzione continua completo richiede mesi e richiede collaborazione. Il controllo della qualità, il team devops, gli ingegneri operativi, gli scrum master: tutti devono contribuire. Forse l'aspetto più difficile di CI / CD è questo fattore umano piuttosto che qualsiasi sfida tecnica di cui abbiamo discusso. Proprio come non puoi programmare una relazione sana tra due persone, non puoi automatizzare la collaborazione e la comunicazione.

Per misurare questo livello di coordinamento, confronta il tuo processo CI / CD con i migliori del settore. Aziende come Netflix possono completare l'integrazione, i test e la consegna nel giro di due o tre ore. Hanno stabilito un sistema che passa il codice di mano in mano senza indecisioni e discussioni. No, non è automatizzato al 100% perché ciò è impossibile con la tecnologia attuale.

Insidia CI / CD n. 5: bilanciare la frequenza di esecuzione di lavori di integrazione continua e l'utilizzo delle risorse

Si suppone che i lavori di integrazione continua vengano attivati ​​per ogni modifica introdotta nel codice. I lavori riusciti consentono l'esecuzione delle modifiche mentre gli errori rifiutano le modifiche. Questo incoraggia gli sviluppatori a controllare blocchi di codice più piccoli, attivando più build in un giorno. Tuttavia, i lavori di integrazione continua non necessari consumano risorse, il che fa perdere tempo e denaro.

Poiché questo processo implica un notevole utilizzo delle risorse (CPU, potenza, tempo), il software dovrebbe essere suddiviso in componenti più piccoli per creare pipeline più veloci. Oppure i lavori di integrazione continua dovrebbero essere progettati per batch check-in che vengono prima testati localmente. L'obiettivo è trovare un equilibrio tra la frequenza di esecuzione di lavori di integrazione continua e l'utilizzo delle risorse.

Mantieni l'obiettivo in vista

Mentre scaviamo nelle insidie ​​di CI / CD, completo di tutta la sua terminologia esoterica, è facile perdere di vista il motivo per cui è importante. In definitiva, CI / CD è essenziale perché soddisfa gli obiettivi aziendali.

I responsabili tecnologici sanno che l'evoluzione continua, soluzioni rapide e risultati di qualità creano e mantengono i clienti. Sanno che un rilascio fallito invita un randello alle recensioni dell'App Store e recuperare recensioni elevate è più difficile che mantenerle. Devops potrebbe creare un'esperienza di lavoro migliore per il tuo team, ma non è questo il motivo per cui le aziende implementano devops.

In poche parole, vale la pena esaminare le insidie ​​di CI / CD perché sono in gioco miliardi di dollari. Anche se non suggerisco di aggiungere un ticker di borsa o un tracker di recensioni dell'App Store alla dashboard CI / CD, ti esorto a rimanere consapevole di questo. Molto dipende dalle minuzie di CI / CD.

Zubin Irani è co-fondatore e CEO di cPrime, una società di consulenza a servizio completo che implementa trasformazioni agili e fornisce soluzioni agili per più di 50 aziende Fortune 100 e molti dei più grandi datori di lavoro della Silicon Valley.

Il New Tech Forum offre un luogo per esplorare e discutere la tecnologia aziendale emergente in profondità e ampiezza senza precedenti. La selezione è soggettiva, in base alla nostra scelta delle tecnologie che riteniamo importanti e di maggiore interesse per i lettori. non accetta materiale di marketing per la pubblicazione e si riserva il diritto di modificare tutti i contenuti forniti. Invia tutte le richieste a [email protected]