Che cos’è e processo di Continuous Development in azienda

Il processo di Continuous Development

Con il termine Continuous Development ci si riferisce ad una serie di tecniche che permettono lo sviluppo iterativo di applicazioni software. Le funzionalità sviluppate, così come le modifiche, diventano immediatamente parte di un prodotto software. Senza bisogno di attendere l’esecuzione di processi di integrazione. A seconda della tecnica adottata, vedremo che il concetto di “immediatamente disponibile” può variare.

Continuous Integration

La Continuous Integration è una pratica tramite la quale gli sviluppatori committano sul sistema SCM il proprio lavoro in modo frequente, almeno una volta al giorno. Ogni commit scatena un processo di compilazione e build della codebase presente nel sistema SCM (esempio GitHub, Svn, ecc.) che la verifica, eseguendo anche una suite di test automatici predisposti dagli sviluppatori. Nel caso qualcosa non vada per il verso giusto durante questo processo di build e test (condizione detta di “build rotta”) gli sviluppatori ricevono notifica immediata del problema e possono porvi rimedio immediatamente, eventualmente facendo rollback del commit che ha causato problemi. Uno dei requisiti della pratica CI è che il codice presente sotto SCM sia sempre compilabile, buildabile e superi i test automatici a cui è sottoposto.

Questo approccio porta ad una significativa riduzione dei problemi di integrazione e permette ai team di sviluppare software coeso in maniera rapida.

Si noti come questa pratica sia in netta contrapposizione ai metodi tradizionali, che prevedono integrazione differita, che avviene solamente a fine sviluppo, dopo un periodo che può durare settimane (ma anche mesi o addirittura anni!) e si pensi anche a quanto problematico possa essere gestire problemi di integrazione che dovessero emergere in questa fase.

Continuous Delivery

La Continuous Delivery è la naturale estensione della Continuous Integration.

Tramite questo approccio, gli sviluppatori garantiscono che ogni modifica apportata al codice, committata sull’SCM ed integrata (Continuous Integration) è potenzialmente rilasciabile in produzione tramite un processo automatico avviato con un click (push button deploy).

Per arrivare ad avere del software rilasciabile è necessario che la codebase presente sull’SCM sia sempre buildabile. Ricordiamo che la build prevede l’esecuzione sul codice compilato di una serie di test automatici volti a garantire il rispetto dei requisiti da parte del software. Le pratiche di Continuous Delivery non escludono completamente l’esecuzione di test manuali che, possono venire eseguiti, per particolari funzionalità critiche non testabili in modo automatico, oppure per funzionalità nelle quali è necessario un feedback utente, prima di lanciare il processo di pubblicazione del software in produzione con un semplice click.

Questa pratica tende a semplificare, in termini di operazioni da compiere, un processo da sempre critico come il rilascio in produzione del software.

Spesso il rilascio viene eseguito raramente a causa sia della complessità delle operazioni da fare, sia per la “paura” che qualcosa vada storto durante queste operazioni unita a quella di rilasciare in produzione software malfunzionante. A questo si aggiunge, talvolta, il fatto che il rilascio ha una durata importante e viene fatto in orari in cui il sistema è sottoposto a carichi minori, che spesso coincidono con orari festivi e/o notturni.

Le pratiche di Continuous Integration e Continuous Delivery permettono di superare agilmente questi limiti introducendo test a copertura del codice prodotto, ed una sequenza automatizzata delle operazioni di rilascio. Tra le conseguenze dei rilasci frequenti una delle più importanti è la riduzione della differenza (delta) tra due versioni consecutive e quindi un rollback non troppo complicato, e al tempo stesso non troppo penalizzante per gli utenti, che dovranno temporaneamente rinunciare alle nuove funzionalità rilasciate.

Continuous Deployment

Lo step successivo è il Continuous Deployment. Tramite questo processo, viene rimosso l’intervento umano minimo previsto dalla Continuous Delivery che avvia il rilascio in produzione del software. Potenzialmente, ogni commit delle modifiche al codice innesca un processo di compilazione, build e testing automatico del software. Qualora la build del codice ed i test automatici abbiano esito positivo, si procede alla crezione di eseguibili (war, exe, jar, ecc.) e, sempre automaticamente, alla pubblicazione in produzione dell’eseguibile generato.

Nei progetti per i quali vengono adottate la Continuous Delivery ed il Continuous Deployment, di norma, non si applicano regole di stop allo sviluppo (code freeze). Trattandosi comunque di metodologie di ispirazione Agile, questo aspetto viene lasciato all’auto-organizzazione degli sviluppatori.

Un concetto fondamentale nel Continuous Deployment è quello di pipeline, un pattern che copre tutte le fasi della produzione software, dallo sviluppo al rilascio. La pipeline modella una sequenza di operazioni che vengono svolte automaticamente, dal momento in cui una modifica software viene committata sull’SCM, a quando questa diviene parte del software rilasciabile. L’esecuzione della pipeline può partire automaticamente ogni volta che vengono effettuati commit sulla codebase del progetto, può essere pianificata per girare ad orari o intervalli predefiniti, oppure può essere lanciata manualmente da personale abilitato a farlo.