Deployment manuali. Rischi evitabili.

Un ciclo tipico mostra dove il lavoro resta in sospeso e quali fasi possono essere eseguite soltanto da singole persone. Consideriamo insieme modifica, build, test, passaggi di consegne e approvazione per la produzione. Non si tratta di eliminare per principio ogni attività manuale. Prima di tutto deve essere chiaro a quale scopo serva e quali informazioni siano necessarie per una decisione. Alcuni ritardi nascono da accessi mancanti, altri da responsabilità poco chiare o da configurazioni diverse. Ognuna di queste cause richiede una soluzione diversa.

Dall'analisi viene sviluppato un primo incarico delimitato. Esso descrive quale parte del processo viene migliorata, quali soggetti collaborano e da cosa si riconosce il risultato. Vengono considerate le procedure funzionanti e gli strumenti già presenti. Così il cambiamento resta gestibile per il vostro team e può essere valutato sulla base di una release reale. Le conoscenze acquisite possono poi essere utilizzate per altre applicazioni, senza dover trasformare fin dall'inizio tutti i processi di sviluppo e di gestione operativa contemporaneamente.

Se test e produzione sono configurati in modo diverso, i test riusciti perdono parte della loro attendibilità. Nell'ambito concordato, l'infrastruttura viene quindi descritta come configurazione tracciabile e versionata. Le modifiche possono essere verificate e attribuite all'ambiente previsto. A ciò si aggiunge un percorso di distribuzione i cui passaggi sono documentati. L'intento non è rendere identico ogni ambiente: le differenze volute restano visibili, mentre le deviazioni non intenzionali possono essere individuate e discusse più facilmente.

I risultati del build, i test e le approvazioni vengono collegati alla rispettiva modifica. Le credenziali richiedono una gestione separata e le modifiche in produzione seguono le decisioni concordate. Viene stabilito insieme quali controlli avvengano in modo automatizzato e dove sia ancora necessaria la valutazione di una persona responsabile. Un ciclo completo mostra se i soggetti coinvolti sappiano utilizzare la procedura e comprendere i risultati. Solo così la pipeline tecnica diventa una procedura su cui sviluppo e gestione operativa possono basarsi insieme nel lavoro quotidiano.

Una procedura di rilascio deve offrire un orientamento anche quando una fase fallisce. Chi valuta l'errore, quali informazioni sono disponibili e quando si può ripetere l'esecuzione? I percorsi di rollback vengono discussi in anticipo, tenendo conto che le modifiche ai dati o le dipendenze esterne possono richiedere un'attenzione particolare. Il ritorno alla versione precedente dell'applicazione non risolve automaticamente ogni conseguenza di una modifica in produzione. I casi di errore concordati vengono quindi esaminati nel processo concreto e, se previsto, testati insieme.

Dopo il passaggio di consegne, anche l'automazione ha bisogno di responsabili. Strumenti, applicazione e infrastruttura cambiano; verifiche e configurazione devono essere mantenute di conseguenza. Il vostro team riceve quindi documentazione e un'introduzione pratica alla procedura concordata. Le limitazioni aperte vengono indicate, invece di essere nascoste dietro un'esecuzione dimostrativa riuscita. Così la soluzione può essere sviluppata ulteriormente dopo la fine del progetto e non resta legata alle conoscenze delle persone che l'hanno allestita in origine.