Caratteristiche e vantaggi del processo di Continuous Deploy in azienda

Da dove cominciare?

Se in condizioni ottimali, quali ad esempio un progetto in fase di avvio, uno o più team di sviluppo software neo costituiti, e così via, implementare queste pratiche può essere una attività relativamente semplice. Nella maggioranza dei casi, però, il team di sviluppo e/o l’azienda si trovano a volere adottare metodologie di Continuous Development partendo da una situazione più o meno tradizionale. La domanda “Da dove cominciare?” sorge quindi spontanea. Le pratiche appena elencate portano tutti i benefici possibili, ma non per forza è necessario iniziare implementandole tutte.

Non c’è una ricetta fissa, molto dipende dal team di sviluppo e dalla natura del sistema su cui si va ad implementare il Continuous Development. Di seguito una sequenza di azioni da intraprendere che potrebbe essere impiegata nella maggior parte dei processi di adozione del Continuous Development.

Un primo passo potrebbe essere l’automatizzazione della build. Mettere tutto il necessario (sorgenti ma non solo) sotto versionamento in modo da poter lanciare la build con un singolo comando. Per molti progetti non è una impresa semplice ed è essenziale per il buon funzionamento di tutte le altre cose. Inizialmente si può partire con build occasionali lanciando manualmente il comando oppure con build automatiche notturne. Una build automatica notturna è un buon punto di partenza.

Successivamente, introdurre alcuni test automatici nel processo di build. Identificare le aree dove si verificano malfunzionamenti più frequenti e predisporre test automatici che siano in grado di evidenziarli. Sui progetti esistenti è difficile avere in tempi rapidi una buona suite di test, predisporli richiede tempo. Da qualche parte si dovrà pur cominciare (“Roma non fu fatta in un giorno“).

Successivamente, provare ad accelerare la commit build. Continuous Integration su una build della durata di qualche ora è meglio di niente, ma portare la durata della build ai dieci magici minuti è molto meglio. Questo di solito richiede parecchia “chirurgia” sulla code base al fine di eliminare le dipendenze dalle parti lente del sistema.

Se si stà invece iniziando un nuovo progetto, applicare metodologie Continuous Development dal principio. Tenere sotto controllo le durate delle build ed intervenire non appena queste superano la regola dei dieci minuti. Intervenendo rapidamente, si metteranno in essere tutte le necessarie ristrutturazioni prima che la code base diventi così grande da rendere dolorose le sue ristrutturazioni.

Ma soprattutto, cercare aiuto. Trovare qualcuno che abbia esperienza in tema Continuous Development, avendovi già lavorato in passato è di grande aiuto. Come ogni nuova tecnica, è difficile introdurla quando non si sa come dovrebbe apparire il risultato finale.

I vantaggi

Il vantaggio più grande e più ad ampio raggio del Continuous Development è la riduzione dei rischi.

Vicolo Cieco

Il problema dell’integrazione differita suggerita dalle metodologie classiche, è che è difficile predire quanto durerà e, peggio, è difficile percepire a che punto si è all’interno del processo. Il risultato è che ci si pone in un vicolo cieco durante una delle parti cruciali del processo di sviluppo di un prodotto software.

Il Continuous Development elimina questo problema. Non c’è processo di integrazione lungo, si elimina completamente il vicolo cieco. Ad ogni momento si sa a che punto si è, cosa funziona e cosa no, ovvero si conoscono i bug presenti nel sistema.

Bugs

I bug sono ciò che tipicamente distrugge confidenza e sicurezza e scompiglia pianificazioni e reputazioni. I bug nel software rilaciato rendono gli utenti “arrabbiati”. I bug durante lo sviluppo ostacolano i programmatori, rendendo difficile il corretto funzionamento del resto del software.

Il Continuous Development non libera dai bugs, ma li rende molto più facili da individuare e rimuovere. A tal riguardo è quasi come avere codice auto testante (self-testing). Se si introduce un bug e lo si individua alla svelta, sarà semplice anche la sua rimozione. La facilità con cui il bug viene individuato deriva direttamente dal fatto che uno o comunque pochi sviluppatori hanno lavorato su una piccola porzione del sistema, apportando piccole modifiche (principio delle modifiche incrementali unito ai commit, ed ai relativi test, frequenti) e che la parte di sistema modificata sarà per forza di cose quella più “fresca” nella mente di chi ha sviluppato le modifiche.

I bug sono cumulativi. Più bugs si hanno, più difficile è rimuoverli. Questo è dovuto in parte al fatto che si possono avere interazioni tra bug, situazioni in cui gli errori sono il risultato di errori multipli, che rendono quindi difficile l’individuazione di ogni singolo errore, ed in parte a questioni psicologiche. Gli sviluppatori hanno meno energia per individuare e correggere bug quando ce n’è più di uno, un fenomeno che viene talvolta individuato come “The Broken Windows Syndrome”.

Come risultato i progetti con Continuous Development tendono ad avere molti meno bug, sia in produzione che in sviluppo. Questo beneficio è sempre rapportato alla bontà della suite di test. Per raggiungere un livello di bug sufficientemente basso è necessario investire costantemente tempo sull’ampliamento e sul miglioramento della suite di tests.

Il deploy frequente è prezioso all’interno del ciclo di sviluppo, soprattutto perché permette agli utenti di avere nuove caratteristiche più rapidamente e di fornire un feedback circa queste nuove caratteristiche altrettanto rapidamente.

Questo aiuta ad abbattere una tra le più grandi barriere che ostacolano un processo di sviluppo software di successo, ovvero le barriere tra clienti (intesi come committenti, Business Owners, Stakeholders, etc…) e sviluppatori.

L’evoluzione ulteriore: DevOps

Nelle organizzazioni tradizionali le funzioni “Development”, ovvero gli sviluppatori, e “Operations”, altri professionisti IT (ad esempio i sistemisti) sono distinte. Semplificando, possiamo dire che le prime si occupano dello sviluppo software, le seconde del rilascio in produzione e del corretto funzionamento di quanto rilasciato.

Le funzioni hanno obiettivi diversi che, paradossalmente, rischiano di entrare in conflitto. Gli sviluppatori (Developers) mirano a rilasciare in fretta funzionalità nuove o migliorate, e quindi rilascerebbero software ogni giorno, mentre le Operations puntano ad avere il sistema sempre funzionante ed efficiente e tendono mantenere le cose allo stato attuale (funzionante) il più a lungo possibile. Questa differenza tende a rallentare i rilasci, e quindi il Business.

DevOps è la combinazione tra i due termini, “Development” e “Operations”. Con questo termine ci si riferisce ad una metodologia di sviluppo software che enfatizza al massimo la collaborazione, la comunicazione e l’integrazione tra sviluppatori software e professionisti IT (sysadmins, DBA, etc.). Lo scopo di questa metodologia è mettere un’organizzazione in grado di fornire prodotti e servizi software in tempi rapidi, evitando i “conflitti” descritti sopra.

Una volta adottate le metodologie Agili, permane comunque una separazione abbastanza netta tra i reparti Sviluppo, IT operations e servizio testing, controllo ed assicurazione qualità (QA). In genere,la separazione è tra le attività di sviluppo e quelle connesse al rilascio. La metodologia DevOps promuove un set di processi ed accorgimenti atti a favorire comunicazione e collaborazione tra i reparti. Processi ed accorgimenti dipendono dall’organizzazione e dagli obiettivi che si intendono perseguire.

Nell’ambito di una organizzazione che eroga un servizio web, un esempio di DevOps potrebbe essere una collaborazione stretta tra Sviluppatori e Tester al fine di predisporre una suite di test automatici e manuali a garanzia e verifica di quanto sviluppato, e tra Sviluppatori e Sistemisti al fine di predisporre uno script automatico che permetta il rilascio in vari ambienti del software sviluppato.