Tempo di rilascio? Da un mese, a poche ore

Da qualche tempo nel reparto sviluppo di MailUp si sentiva fortemente la necessità di rivedere il processo di rilascio in produzione delle console, per automatizzare e velocizzare il più possibile tutte le fasi coinvolte e aumentare il controllo sull’intero processo.

In un blog post di un paio di anni fa, il CEO Nazzareno Gorni indicava per MailUp 8.1 un tempo di rilascio non in linea con i requisiti evolutivi della piattaforma.

L’ultimo aggiornamento (versione 8.6.3) su oltre 10 mila console, tra clienti e trial, ha invece richiesto poche ore: MailUp registra così importanti passi verso una sensibile riduzione dei tempi che intercorrono tra lo sviluppo di una nuova funzionalità (o di una correzione) e il momento in cui, mettendo in produzione le modifiche sviluppate, si fornisce al cliente un miglioramento del servizio.

Non va dimenticato, infine, il contributo di questo processo sulla qualità finale del prodotto: automazione significa anche esecuzione di un numero sempre più crescente di verifiche sul codice sorgente, sia in fase di sviluppo sia come lavoro preliminare sulle operazioni di aggiornamento delle console.

La fase di rilascio: opportunità o seccatura?

Spesso la fase di rilascio è vista dagli sviluppatori come una seccatura e una perdita di tempo. Questo fa sì che sia relegata e trascurata soprattutto in fase di startup di un progetto, dove l’attenzione è indirizzata maggiormente alla progettazione, al design e allo sviluppo.

Prima o poi, però, arriva il momento di far vedere agli utenti finali quanto si è fatto e il rilascio improvvisamente diventa fondamentale e soprattutto urgente. Inoltre, man mano che gli sviluppi procedono, il rilascio diventa sempre più complesso e rischia di diventare critico.

Per questo, noi di MailUp, crediamo che le attività di rilascio vadano affrontate fin dalle prime fasi del progetto: esse possono essere paragonate alle radici di un albero, che non si vedono ma sono fondamentali.

Le attività di rilascio servono a scongiurare errori nella configurazione, dunque malfunzionamenti e regressioni nella novità su cui si è lavorato per mesi. Per evitare che ciò accada, in questi mesi abbiamo lavorato in sinergia con il reparto IT sull’automatizzazionedelle procedure di rilascio.

La nuova procedura di rilascio

Oggi, quando uno sviluppatore “salva” le sue modifiche (commit) in un determinato luogo (Version Control System), partono immediatamente delle procedure che elaborano e testano il codice modificato (come farebbe lo sviluppatore a mano) e con quest’ultimo aggiornano le console di test (preproduzione) a uso interno (Pre-Alpha). Tutto avviene in pochi minuti, in modo completamente automatico, sicuro e ripetibile.

Questa pratica si chiama “continuous integration” e permette di:

• avere un feedback immediato sulla modifica introdotta
• avere console costantemente aggiornate su cui effettuare ulteriori test
• integrare il lavoro di tutti gli sviluppatori
• avere maggiore confidenza con il processo di rilascio (i file corretti nel posto giusto)
• risparmiare prezioso tempo, senza investirlo in noiose operazioni manuali facilmente soggette a errori

Al momento di andare in produzione con i nuovi sviluppi, la procedura automatica esegue i seguenti passi:

1. crea una copia (branch) del codice modificato (Freeze) e su questa vengono eseguite le procedure citate sopra
2. aggiorna le console di test interne (Alpha) e poi le console di produzione seguendo questo ordine: prima le console di produzione a uso interno (Beta) per eventuali fasi di QA e integration test, in seconda istanza, a fronte di esito positivo di test e previa autorizzazione manuale, le console dei clienti betatester (Release Candidate) e infine i clienti (Gold).

Per eseguire un bug-fix in produzione, basta salvare le modifiche direttamente sulla copia (branch) fatta nel passo 1 dell’ultimo rilascio; l’esecuzione di questa operazione farà partire in automatico la procedura descritta al passo 2 che porterà il bug-fix fino alla preproduzione e poi in produzione.

Per eseguire le operazioni di cui sopra, ci vengono in aiuto “Jenkins CI” e “Octopus Deploy“.

Il primo, più conosciuto e usato, è un software Open Source di Continuous Integration che si occupa di far partire tutta la procedura (step 2 Fig.2) a fronte di una modifica del codice (step 1), tenere traccia della modifica, eseguire tutti i test unitari e di integrazione automatici, compilare il codice, creare un pacchetto (nuget) con tutti i file da portare (step 3), pubblicare il pacchetto su un server, creare e inviare email di notifica e infine “svegliare” Octopus Deploy (step 4).
Octopus Deploy, a sua volta si occupa di prendere il pacchetto creato da Jenkins (step 5),trasferirlo sulle console da aggiornare (Deploy) apportando tutte le modifiche necessarie ai file di configurazione (step 6) e interagire con i web server per creare eventuali nuovi siti.

Queste procedure di rilascio rappresentano un pattern applicabile a qualsiasi progetto.

Cosa cambia rispetto a prima

Per il rilascio 8.6.3 è stato adottato DbUp, un tool open source che si occupa dell’aggiornamento dei database e che viene eseguito contemporaneamente su più database.

Questo tool offre i seguenti vantaggi:

• crea su ogni database aggiornato una tabella di servizio (SchemaVersions) che tiene traccia degli script eseguiti
• utilizza poi questa tabella per eseguire solo script nuovi
• permette di conoscere esattamente quali script sono stati eseguiti e quando su ogni console
• dato che gli script sono eseguiti in transazione, consente, in caso di errore, di mantenere la console nello stato originale
• lavorando in parallelo, i tempi di aggiornamento risultano sensibilmente ridotti

Sempre più competitivi

L’insieme di test automatici per la validazione delle modifiche e la verifica sull’assenza di regressioni è in continua espansione, la sua manutenzione ed evoluzione fa parte dei compiti di ciascuno sviluppatore.

L’uso di questa metodologia e dei tool citati permette di avere un censimento costantemente aggiornato dei progetti esistenti, consente di rilasciare ogni progetto in modo più sicuro, ripetibile e tracciato.

Tutto questo ci permetterà di intervenire con maggior tempestività sulle segnalazioni di bug ed essere maggiormente reattivi alle richieste.

Questo articolo è stato scritto da

Andrea Serventi