Gestione delle versioni

La gestione delle release è la disciplina che si occupa di pianificare, programmare e controllare il passaggio delle modifiche software in produzione. Comprende cosa è incluso in una release, come viene verificato, come viene distribuito, come viene monitorato successivamente e come viene annullato in caso di problemi. Il suo obiettivo è rendere la transizione dalla versione di sviluppo a quella di produzione un processo di routine, anziché un evento problematico.

La scoperta più ricorrente in questo ambito contraddice l'intuizione. Le release di grandi dimensioni sembrano più sicure perché concentrano il rischio in un unico evento attentamente gestito, ma le evidenze provenienti dalla ricerca sulle prestazioni di distribuzione indicano il contrario: le release di piccole dimensioni e frequenti producono tassi di errore inferiori e un ripristino più rapido. Una release di grandi dimensioni raggruppa molte modifiche, quindi quando qualcosa si rompe è difficile isolarne la causa, e il rollback scarta tutto anziché la singola modifica difettosa.

L'automazione del deployment è il fondamento che rende possibile la frequenza di rilascio. Le procedure di deployment manuali sono lente, incoerenti e soggette a errori, e il loro costo per rilascio crea la pressione per raggruppare le modifiche, il che produce proprio quei rilasci di grandi dimensioni che comportano maggiori rischi. Automatizzare la pipeline in modo che il deployment sia ripetibile e senza intoppi elimina l'incentivo ad accumulare.

Separare la fase di implementazione da quella di rilascio è la tecnica che più di tutte modifica il profilo di rischio. Distribuire il codice in produzione con una funzionalità disabilitata tramite un flag, per poi abilitarla separatamente, significa che l'atto tecnico di rilasciare il codice e l'atto commerciale di esporre la funzionalità non coincidono più. I problemi in fase di implementazione vengono individuati senza che gli utenti ne risentano, e le funzionalità possono essere esposte progressivamente e ritirate istantaneamente senza dover ridistribuire nulla.

Da questa separazione deriva naturalmente un'esposizione progressiva. Rilasciare il prodotto a una piccola percentuale di traffico, monitorare i tassi di errore e le metriche aziendali ed espandere gradualmente il prodotto limita la portata di qualsiasi problema a una frazione di utenti. Questo approccio è considerevolmente più efficace dei test pre-rilascio estesi per individuare la tipologia di problemi che si manifestano solo in condizioni di produzione reali, con carico e dati effettivi.

La capacità di rollback deve essere verificata anziché data per scontata, ed è proprio in questo ambito che molte organizzazioni scoprono un problema nel momento peggiore. Una procedura di rollback documentata ma mai eseguita spesso fallisce quando serve, soprattutto in caso di migrazioni di database in cui la modifica dello schema non può essere semplicemente annullata. Esercitarsi con il rollback e progettare le migrazioni in modo che siano retrocompatibili, così che la versione precedente continui a funzionare, è ciò che rende la rete di sicurezza realmente efficace.

Il monitoraggio successivo al rilascio è parte integrante del processo, non una questione separata. Un rilascio non è completo quando l'implementazione ha successo; è completo quando si osserva che il sistema funziona correttamente in condizioni di traffico reale. Definire in anticipo quali indicatori monitorare, per quanto tempo e quale soglia attiverebbe un rollback trasforma il periodo post-rilascio da una vaga sorveglianza in una fase definita con una decisione associata.

La comunicazione relativa alle release è più importante di quanto i team si aspettino, soprattutto quando le modifiche sono visibili ai clienti o riguardano utenti interni che devono essere preparati. I team di supporto devono essere informati sulle modifiche prima che i clienti le chiedano, e le modifiche non annunciate all'interfaccia generano un volume di contatti sproporzionato rispetto alla loro entità. Un avviso breve e affidabile, che raggiunga le persone che risponderanno alle domande, ha un costo contenuto e previene una prevedibile tipologia di disagi.

Poiché la pratica di rilascio è determinata tanto dall'infrastruttura di distribuzione sottostante quanto dal processo, il miglioramento richiede solitamente investimenti ingegneristici piuttosto che modifiche procedurali. In pratica questo viene stabilito all'interno sviluppo del prodotto, il monitoraggio post-rilascio si basa sulla misurazione mantenuta attraverso analisi dei dati in modo che venga osservato l'impatto aziendale piuttosto che solo la salute tecnica, e nelle organizzazioni che gestiscono molti servizi gli standard sono in genere di proprietà dell'intero Reparto IT piuttosto che stabilire squadra per squadra.