Dark Launching

Il Dark Launching è una tecnica, utilizzata da Facebook, AirBnB e dai maggiori distributori di servizi software, per la gestione delle Release in maniera graduale e

controllata. Secondo il Dark Launching è possibile iniziare a convertire parte del va- lore potenziale di una feature anche prima del momento strategico ottimale, la nuova

feature viene quindi messa a disposizione di un piccolo sottoinsieme di utilizzatori, consci o inconsci.

Il piccolo subset di istanze complete viene quindi monitorato nel dettaglio per

mettere in luce le performance in produzione, in vista dello scaling, il grado di sod- disfazione dei clienti e l’eventuale presenza di bug e anomalie sfuggite al Continuous

Testing.

Figura 3.11: Facebook Dark Launching secondo Facebook

Facebook adotta un rilascio in tre fasi per la gestione degli aggiornamenti più significativi:

1. La nuova feature viene rilasciata tra i dipendenti dell’azienda, monitorando il prodotto e garantendo la presenza di un "arresto forzato" prima dell’effettivo

rilascio.

2. Si passa quindi al rilascio del 2% in produzione, in questa fase si colleziona-

no segnali di alert, ponendo grande attenzione ad eventuali sovraccarichi del sistema o ai punti più critici della feature.

3. La feature viene infine rilasciata in produzione ed inserita nel processo di Continuous Monitoring.

3.12

Continuous Deployment

Il Continuous Deployment consiste nella completa industrializzazione del processo di

sviluppo e distribuzione del prodotto software. Anche il Deploy viene automatizzato creando un effettivo flusso di rilasci generato dalla semplice pressione di un pulsante.

Il Continuos Deployment non è però una tecnica adatta a tutte le aziende, rag- giungere un tale livello di automazione presuppone infatti la completa comprensione

e adozione delle pratiche precedenti e un alto livello di fiducia nella Deployment

Pipeline.

Figura 3.12: Delivery e Deployment

Eliminare ogni intervento umano implica che ogni fase del processo sia imple-

mentata al meglio:

Una sola compilazione

Il software deve essere compilato una e una sola volta, in un ambiente identico a quello di produzione, isolato e monitorato. La Deployment Pipeline deve poter

identificare in maniera univoca ogni singolo prodotto compilato e testato in modo da poter selezionare il miglior candidato o eliminare quelli corrotti.

Test come unica garanzia di qualità

La Deployment pipeline deve contenere test perfetti, in grado di garantire la mas- sima copertura e il massimo livello qualitativo, come richiesto dagli standard di

produzione. E’ inoltre necessario introdurre Smoke Tests in grado di verificare che l’ambiente di esecuzione sia consistente con le specifiche e che il prodotto sia

effettivamente attivo e funzionante.

Processo di Deployment industrializzato

Anche il processo di Deployment deve essere automatizzato e gestito con compo- nenti software al pari del prodotto in sviluppo. Il processo deve essere testabile,

documentato, convergente e idempotente, in modo da poter essere ripetuto in qual- siasi ambiente della fase di produzione. Utilizzando lo stesso metodo per ogni stage

si ha la possibilità di verificare l’efficacia dello stesso ben prima del suo effettivo utilizzo in produzione.

Ambienti standardizzati

Per poter standardizzare il deploy è necessario prima di tutto che gli ambienti siano

standardizzati, secondo i principi del Configuration Management.

3.12.1

Blue/Green Deployment

Il Blue/Green deployment è una tecnica che permette di gestire in maniera graduale

e controllata il Continuous Deployment di un software, solitamente di un servizio web.

L’ambiente di produzione viene replicato, ottenendo due ambienti gemelli chia- mati Green Environment e Blue Environment, il primo conterrà l’attuale versione

Figura 3.13

del software, utilizzato dal 100% dell’utenza, il secondo sarà dedicato al rilascio del- la nuova versione. Un terzo elemento dell’infrastruttura si occupa di dirottare una

percentuale definita di utenti dalla vecchia alla nuova versione, completa di tutte le nuove funzionalità. La transizione tra Blue e Green è graduale e incrementale,

l’utenza viene mano a mano dirottata fino al completo abbandono del Green Envi- ronment, durante questa fase si monitorano le performances della nuova istanza allo

scopo di rilevare criticità e problemi di scaling.

Al termine della transizione la vecchia istanza può essere mantenuta, al fine di poter effettuare un rollback in caso di necessità, oppure disabilitata. In ogni caso

assumerà il ruolo di pilota al successivo rilascio.

Il B/G Deployment si differenzia dal Dark Launching per la necessità di avere due ambienti di produzioni differenti, in ogni caso la configurazione dell’istanza

aggiornata può essere gestita con le Toggle Features, inoltre le features sono rilasciate a un subset in continua transizione fino alla totale copertura.

3.12.2

Oltre il prodotto

Nelle sezioni 3.7 e 3.8 sono presentate le metodologie per convertire gli script di Provisioning e Orchestration in componenti software, in tutto e per tutto gestibili

allo stesso modo del prodotto sviluppato.

Questo significa che è possibile creare una Continuous Deployment Pipeline anche

per l’infrastruttura sul quale è rilasciato il software: ogni nuova modifica alla con- figurazione delle istanze o all’architettura stessa viene quindi inserita in un VCS,

testata, integrata ed applicata in maniera continua e automatizzata.

3.13

Continuous Monitoring (CM)

Il Continuous Monitoring rappresenta la chiusura del feedback loop, fondamentale

per il miglioramento incrementale del processo di produzione. Il lavoro del team non

termina con il rilascio in produzione, il prodotto deve essere infatti costantemente monitorato per assicurare che le specifiche funzionali e non funzionali siano garantite

sul lungo termine. Allo stesso modo, anche la Deployment Pipeline e il lavoro del team deve essere monitorato per garantire che tutto funzioni secondo i più elevati

standard di efficienza.

3.13.1

Monitoring post-produzione

Il prodotto deve esser progettato fin dalle prime fasi del processo di sviluppo per

integrare strumenti di controllo atti a valutarne il funzionamento:

Test in produzione

Gli stessi test eseguiti nella Deployment Pipeline devono poter essere eseguiti pe-

riodicamente sul software in produzione, in modo da verificare costantemente che tutto funzioni senza problemi.

Metriche

Il Software deve esporre una serie di Metriche (KPI), valori atti a valutare il fun- zionamento del prodotto in modo significativo e duraturo. La definizione dei KPI

è strettamente legata all’applicativo del caso. Per un servizio web è significativo monitorare il tempo di risposta alla singola richiesta, oppure il numero di richieste

giornaliere; per un modello di previsione è interessante verificare che l’errore fatto sulla predizione converga allo zero.

Due sono i metodi solitamente utilizzati per esporre metriche:

White Box La generazione ed esposizione delle metriche è parte integrante del codice dell’applicativo, KPI di questo tipo sono molto significativi perchè danno

un valore costantemente aggiornato sul corretto funzionamento. Un esempio di KPI White-box è l’errore sulla singola previsione.

Black Box Le metriche sono periodicamente collezionate da un software esterno che valuta gli effetti del prodotto sull’ambiente di esecuzione. Ad esempio, una me-

trica black box è lo stato di funzionamento di un determinato servizio, o il numero di elementi salvati in un database al termine dell’ultima esecuzione di un processo

Batch.