Termini come Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps, ecc, sono orami entrati nel gergo comune del mondo dello sviluppo software, complice il cambio di paradigma che inesorabilmente ha interessato l’Application Lifecycle Management (ALM) negli ultimi anni.

Risalendo alle origini comuni che ritroviamo in Agile, e in Lean prima per certi aspetti, la Continuous Delivery è esplicitamente descritta dal primo principio Agile:

“La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua”

La Continuous Deliverynon è esclusivamente un insieme di strumenti e pratiche, ma enfatizza la capacità delle Personedi instaurare una Relazione Sociale(Cultura) e sfruttare Toole Processi per generare Valore continuo per l’utente finale, in funzione di quattro principi fondamentali:

• Il software è sempre rilasciabile, il che significa che la priorità è mantenere il software distribuibile piuttosto che aggiungere nuove funzionalità. Per fare ciò, si prediligono modifiche atomiche (piccole), e meno rischiose, rilasciate continuamente piuttosto che

tutte in una volta

• Le attività di gestione dei requisiti (backlog), la loro formalizzazione ed il loro aggiornamento sono parte integrante del ciclo di valore
• Un (veloce) feedback loop delle fasi di compilazione, teste deployconsente a tutti gli attori coinvolti di stabilire se è possibile approvare un rilascio immediato in qualsiasi ambiente
• L‘automazione del processo di build, teste deployè fondamentale per rendere il processo ripetibile e per supportare una maggiore frequenza del tutto

La Continuous Deliveryimpone letteralmente di mantenere il software sempre in uno stato rilasciabile: nulla può andare in produzione senza aver prima superato i test e le validazioni previste! Tale stato di rilasciabilità consente di spostare con confidenza la build in qualsiasi ambiente in qualsiasi momento. 

Tutto ciò implica l’adozione di pratiche Agili che aumentano la frequenza di build, test e deploy, grazie al supportato di strumenti che ne automatizzano le parti ripetitive.

La Continuous Deploymentsi occupa di automatizzare lo “spostamento” della build su un qualsiasi ambiente, azione supportata da strumenti di configurazione automatica e test di varia natura. Per efficientare il tutto si ragiona intermini di Deployment Pipeline, andando ad automatizzare il più possibile il flusso che porta dalla Continuous Integration(in seguito al check-in del codice) fino al rilascio su diversi ambienti previsti, ognuno con specifici test. 

La Continuous Deployment è quindi un assett tecnico/tecnologico a supporto della Continuous Delivery, rendendo le attività di compilazione/deploy/test, affidabili, elastiche, e capaci di adattarsi automaticamentealle modifiche al codice, agli aggiornamenti dei repository dati e alle configurazioni del server. In pratica avremo:

• Continuous Build, supportato da script e tool per la Build Automation
• Continuous Deploy, supportata da script e tool per l’Application Release Automation
• Continuous Testing, supportato da script e tool per Testing Automation e Virtualization

Una delle rappresentazioni classiche che crea confusione è quella della figura seguente:

In cui si minimizza la differenza tra Continuous Delivery e Continuous Deployment nella sola automazione dell’intera catena, rappresentando addirittura la Continuous Deployment come uno step successivo alla Continuous Delivery. Un po’ poco per giustificare l’esistenza di due terminologie che creano tanta confusione e che differiscono “solo” in un passaggio automatizzato in più, senza, tra l’altro, allargare lo scopedella rappresentazione anche alle fasi di planning e coding. Se si ritiene di voler automatizzare anche il deploy in produzione resta una opportunità e una scelta di business, che può variare anche nel tempo, ma la Delivery ha sempre l’aspetto intrinseco di “guardare all’utente”.

Una possibile rappresentazione più significativa, che abbraccia quanto ci siamo detti, nobilitando la Continuous Delivery è la seguente:

In cui è toccato tutto il ciclo ALM e la Delivery è effettivamente letta in chiave Agile/Lean.

Stay tuned J