Formazione scritta DevOps

Come progettare la pipeline DevOps di rilascio e deployment continui?

In molte organizzazioni, probabilmente anche nella tua, gli sviluppatori scrivono codice in isolamento, su rami separati. Questo modo di lavorare sembra favorire la produttività individuale, ma penalizza quella del team.

I rami separati rendono difficile integrare il codice di più sviluppatori. Per integrare parti di codice diverse, farle funzionare insieme e offrire funzionalità e vantaggi ai clienti, di solito occorre coinvolgere più sviluppatori, rifare molto lavoro e risolvere conflitti che si sarebbero dovuti affrontare tempo prima.

Senza integrazione continua, il problema si aggrava

Per ironia, poiché l'integrazione del codice è faticosa e impegnativa nei cicli di sviluppo, la maggior parte dei team unisce il codice solo prima di consegnare l'applicazione a chi esegue i test di integrazione o di accettazione utente, aggravando il problema. Attribuisce al team di assicurazione della qualità tutta la responsabilità dell'integrazione e della qualità del lavoro congiunto. È assurdo e spiega bene perché i progetti ritardano, il disavanzo del budget cresce a dismisura, il morale e la motivazione calano, gli obiettivi e le promesse dell'organizzazione non vengono rispettati e le aziende di tutto il mondo sprecano ogni anno circa 600 miliardi di USD per lavoro IT fuori budget e non pianificato. O, per dirla diversamente, per rifare il lavoro e mettere in atto soluzioni di ripiego.

Come può aiutarti lo sviluppo basato sul trunk, il ramo principale del codice?

La soluzione è lo sviluppo basato sul trunk, il ramo principale, insieme all'integrazione continua e all'automazione dei test. È un modello di controllo di versione in cui gli sviluppatori collaborano sul codice in un unico ramo, chiamato «trunk». Resistono alle pressioni per creare altri rami di sviluppo di lunga durata.

Lo sviluppo basato sul trunk è fondamentale per l'integrazione continua e quindi per il rilascio continuo. Quando gli sviluppatori registrano le proprie modifiche nel trunk più volte al giorno, è facile soddisfare il requisito essenziale dell'integrazione continua, cioè che tutti i membri del team facciano almeno un commit nel trunk ogni 24 ore. Questo fa sì che il codice sia sempre rilasciabile su richiesta e aiuta a rendere concreto il rilascio continuo.

L'integrazione continua ti permette di consegnare il codice in lotti più piccoli e pronti per il deployment

I check-in frequenti degli sviluppatori consentono inoltre di sviluppare e rilasciare lotti più piccoli, migliorando la qualità e semplificando la risoluzione di problemi e conflitti. L'integrazione continua con check-in giornalieri spinge il team a creare porzioni di codice più piccole, ma significative e distribuibili, senza compromettere l'integrità dei framework di integrazione e rilascio continui. Gli aggiornamenti del repository condiviso facilitano inoltre il coordinamento, le decisioni e lo scambio di feedback.

A ogni check-in, il framework di integrazione continua esegue i casi di test automatizzati per le funzioni che dipendono dal modulo modificato o ne subiscono l'impatto. Se qualcosa si rompe, chi ha eseguito quel check-in deve correggerlo con la massima priorità. In quel momento nulla è più importante di consentire al resto del team di continuare a integrare il lavoro nel trunk. Finché il check-in errato non viene corretto o annullato rapidamente, non si possono fare altri check-in in quel modulo del trunk, per tutelarne la stabilità e l'affidabilità.

Se non condividi questo principio DevOps fondamentale, chiediti perché vorresti aggiungere altro codice a un modulo che contiene già errori.

Potresti avere motivi validi, ma assicurati di evitare debito tecnico e soluzioni di ripiego sovrapposte.

I commit soggetti a verifica proteggono ulteriormente lo sviluppo basato sul trunk

Il team DevOps può anche usare commit soggetti a verifica (gated commit), che migliorano ulteriormente la qualità e aggiungono un livello di protezione al trunk.

Ogni volta che uno sviluppatore tenta di effettuare il check-in di codice, vengono eseguiti prima i test automatizzati per convalidarlo. Il codice viene registrato formalmente nel trunk soltanto dopo una convalida riuscita.

Usa ambienti simili alla produzione in ogni fase del flusso di valore dell'ingegneria del software

Un altro problema comune nelle organizzazioni IT è la mancanza di coerenza tra produzione e preproduzione, inclusi gli ambienti di sviluppo, integrazione e test. Possono differire configurazioni, versioni e livelli di patch di sistemi operativi, database, strumenti di terze parti e API. Oppure versioni diverse del tuo codice possono essere sparse tra ambienti di produzione e preproduzione. Anche differenze minime tra le versioni della JVM nei due ambienti possono determinare il successo o il fallimento dell'intero deployment in produzione. Se non hai il pieno controllo degli ambienti e non sai che cosa contengono, non puoi prevederne i risultati.

Integra la gestione degli ambienti nel lavoro quotidiano di sviluppo e rilascio

Gli ambienti di preproduzione dovrebbero quindi replicare quelli di produzione. Metti il team in condizione di creare ambienti self-service su richiesta e in modo automatizzato, così può svolgere in sicurezza le attività quotidiane di ingegneria del software in ambienti simili alla produzione.

Il flusso di valore IT offre valore tramite il codice del software e gli ambienti in cui viene eseguito. Gli specialisti di sviluppo e attività operative devono riconoscere che il flusso di valore IT ha due componenti ugualmente importanti:

1. Codice per creare software che offre valore ai clienti interni e/o esterni.
2. Codice per creare gli ambienti di preproduzione e produzione che ospitano il software.

Usa il trunk come unica fonte di verità per controllare software e ambienti
(ovvero adotta l'Infrastructure as Code, IaC)

Con DevOps, le attività per creare gli ambienti di preproduzione e produzione fanno parte del trunk. È la definizione più pura di Infrastructure as Code (IaC). Gli specialisti di sviluppo e attività operative lavorano insieme per creare l'infrastruttura come codice, superando l'isolamento dei team operativi che conoscono a malapena le specifiche del software da ospitare.

Per dare pari importanza al codice del software e a quello degli ambienti, li conservi entrambi nell'unica fonte di verità, il trunk.

Per creare tutti i sistemi di preproduzione e produzione e la pipeline di deployment con i framework di integrazione e rilascio continui, tu e il team conservate nel sistema di controllo di versione il codice, le configurazioni, gli script e tutto ciò che serve per creare l'intera catena di rilascio. Se vuoi modificare in modo permanente una configurazione, aggiornala negli script di creazione dell'ambiente. Così la prossima persona del team che crea un ambiente non dovrà rifare il lavoro.

Gran parte della documentazione dettagliata diventa presto obsoleta. Conviene quindi investire il proprio impegno per mantenere aggiornati gli script di creazione degli ambienti. Senza ambienti self-service e su richiesta, l'infrastruttura cloud resterà una piattaforma di hosting sottoutilizzata e l'iniziativa DevOps un tentativo di miglioramento poco sfruttato. Dovresti poter creare interi ambienti di produzione e preproduzione a partire dal sistema di controllo di versione. Con DevOps è più semplice e veloce ricreare gli ambienti che ripararli. Non sono più ammesse modifiche manuali. Solo codice e configurazione dovrebbero ricreare, configurare e avviare gli ambienti.

Hai una nuova Definition of Done (DoD)

Con il framework di rilascio continuo e la pipeline di deployment operativi, serve una nuova Definition of Done (DoD).

Un'attività si considera completata quando le funzionalità e i vantaggi per i clienti a essa associati sono:

• creati dal trunk automaticamente o con un solo clic,
• verificati in ambienti simili alla produzione con test automatizzati,
• mostrati in ambienti simili alla produzione,
• pronti per il deployment o, meglio ancora, già distribuiti in ambienti di produzione attivi, anche in questo caso automaticamente o con un solo clic.

CONCLUSIONE

Con DevOps integri il codice nel lavoro quotidiano, anziché alla fine dei progetti. Sviluppatori, team operativi e specialisti della sicurezza delle informazioni provano più volte a distribuire il lavoro già durante il ciclo di ingegneria del software. Ciò aumenta senz'altro le probabilità che i deployment effettivi riescano senza intoppi.

Con l'integrazione continua otterrai anche maggiore produttività aziendale, più stabilità del software e degli ambienti, maggiore soddisfazione sul lavoro e servizi migliori per i clienti interni ed esterni.