Sveliamo le strategie di sviluppo software, continuous integration e continuous delivery alla base di Slope, un SaaS Cloud con più di 200 rilasci all’anno.

In questo articolo vogliamo raccontare ai lettori più curiosi del blog alcuni dei retroscena tecnici alla base dell’architettura software, dal processo di sviluppo a quello di rilascio del software Slope. L’articolo è rivolto anche a tutti coloro che non fanno parte della limitata nicchia degli “addetti ai lavori”, cioè quelli che non operano direttamente nell’ambito dello sviluppo software, ma vogliono comunque capire quali sono gli accorgimenti e le strategie scelte dal team di ingegneriche operano quotidianamente allo sviluppo della piattaforma Slope.

Quando si è intenzionati ad acquistare un prodotto, è importante fare valutazioni approfondite con l’obiettivo di capire bene i pregi ed i difettidel bene che si sta acquistando.
L’acquisto di un software non fa eccezione, per questa ragione noi di Slope vogliamo essere trasparenti e raccontarvi quali sono le ragioni che permettono alla nostra piattaforma di essere stabile, veloce e soprattutto estremamente espandibile e flessibile. Partiamo dal presupposto che sviluppare e mantenere un software cloud SaaS non è cosa facile, soprattutto se si tratta di un software utilizzato quotidianamente da diverse migliaia (se non milioni) di utenti. Le problematiche quotidiane da affrontare e gestire sono molteplici e crescono in modo esponenziale all’aumentare del carico e del traffico, quindi all’aumentare degli utenti sulla piattaforma. Per questa ragione, e per tutte quelle che vi stiamo per descrivere, è importante che l’azienda abbia a disposizione un team di tecnici (sviluppatori e ingegneri informatici) che siano preparati e specializzati nello sviluppo e mantenimento, sia delle applicazioni web ma anche dell’infrastruttura che le mette a disposizione.

Volendo fare una carrellata di alcune delle principali problematiche che sono intrinseche nello sviluppo e manutenzione di un software cloud possiamo elencare:

• Garantire uptime del servizio;
• Avere cicli di sviluppo del codice efficienti;
• Effettuare rilasci del codice rapidi e senza regressioni;
• Gestione dell’infrastruttura (server);
• Monitorare le performance e i log di sistema.

Continuous Integration (di seguito CI) e Continuous Delivery (di seguito CD) sono due paradigmi ben noti a chi si occupa di sviluppo software per il web, sono però poche le aziende che riescono a mettere in pratica queste metodologie su progetti medi e grandi. Cerchiamo di capire di cosa si tratta e perché è così difficile.
Continuous Integration (CI) è la modalità secondo la quale ogni sviluppatore del team lavora a funzionalità del sistema apportando cambiamenti il più limitati possibile, che possono essere integrati velocemente alla codebase comune a cui tutti gli altri membri del team attingono.

Con questa tecnica si cerca di evitare che sviluppatori lavorino a funzionalità molto grandi per un intervallo di tempo troppo lungo (ad esempio più di 4-5 giorni). In questo caso, infatti, diventerebbe difficile e rischioso re-integrare tale funzionalità nel sistema che nel frattempo è evoluto grazie al lavoro di altri sviluppatori.
Questo garantisce che ogni sviluppatore lavori a una versione del codice il più vicina possibile allo stato del codice di produzione. Inoltre, ogni qual volta che un cambiamento viene effettuato (aggiunta, rimozione o modifica di codice) si avvia un processo automatico di testing che garantisce che il software continui a funzionare correttamente anche nella sua nuova versione.

 

Prima di tutto, per fare in modo che la CI possa essere applicata con successo, è necessario che la piattaforma software (nel nostro caso il software Slope) sia corredata di una suite di test automatici in grado di verificare il corretto funzionamento di tutte le funzionalità del sistema con un buon livello di precisione.
Quindi, su di una codebase non sufficientemente corredata da test automatici non si potrà applicare la strategia di CI con successo; il motivo è che viene meno la possibilità di verificare automaticamente che il corretto funzionamento del sistema sia mantenuto ogni volta che si interviene al codice.

La piattaforma Slope è corredata da una rete di test automatici molto minuziosa e ben bilanciata tra i diversi tipi di test (unitari, integrazione e funzionali, anche conosciuti con il termine “end to end”).
Grazie all’attenzione e al rigore che i nostri sviluppatori hanno posto nella scrittura di test automatici sin dal primo giorno, possiamo operare in sicurezza sapendo che le modifiche apportate al codice (che possono essere la scrittura di nuove funzionalità, l’ottimizzazione di funzioni esistenti o risoluzione di bug) con alta probabilità non causeranno rotture alle funzionalità del sistema già esistenti ed in uso.

Quindi per capire bene in quale parte del processo di sviluppo software ha senso parlare di CI possiamo dire che questa subentra nel momento in cui lo sviluppatore ha ultimato la scrittura del proprio codice (che deve essere rigorosamente corredato da test automatici, sempre!) e invia il proprio codice ad un repository GIT ospitato su un server remoto.

Nel momento in cui lo sviluppatore effettua il “push” (invio del codice), viene chiamato in causa il server di Continuous Integration che avrà il compito di copiare il nuovo codice scritto e lo unirà al resto della piattaforma per poi eseguire in isolamento tutte le verifiche di conformità del codice.
Per darvi un’idea le verifiche consistono nell’ordine:

• Verifica stilistica del codice;
• Analisi statica del codice;
• Verifica della conformità della definizione del modello dei dati;
• Esecuzione dei test unitari;
• Esecuzione dei test di integrazione;
• Esecuzione dei test funzionali su tutte le applicazioni della piattaforma;

 

Se il codice soddisfa tutti i test (e per saperlo dobbiamo aspettare circa 20 minuti) allora questo passa in revisione ad uno degli ingegneri (ovviamente non lo stesso che ha scritto il codice). È suo compito verificare che le modifiche introdotte soddisfino tutti i criteri di sicurezza ed efficienza, e se così è allora il codice viene approvato per l’inclusione nella codebase principale (“master”), cioè quella candidata ad essere messa sui server di produzione al prossimo rilascio.

A questo punto abbiamo del codice che non solo è stato scritto seguendo una serie di requisiti tecnici molto stringenti ma soprattutto siamo ragionevolmente sicuri che questo non vada a rompere funzionalità già esistenti e in uso dagli utenti.

A questo punto entra in gioco il concetto di Continuous Delivery (CD), cioè il processo di creazione della “build” e della messa in produzione del codice. Tale processo è automatico (sebbene pilotato dagli ingegneri) e, con il solo click di un tasto, nel giro di circa 5 minuti la build del codice aggiornata viene rilasciata sul nostro ambiente di “staging”.
Staging è un ambiente intermedio (una sorta di “pre-produzione”) che replica la configurazione e l’architettura dell’infrastruttura di produzione, sulla quale il nostro team generalmente effettua smoke-testing con dati pseudo-reali per assicurarsi che non ci siano problemi macroscopici che la suite di test non è stata in grado di rilevare.

Una volta che tali verifiche sono completate (generalmente in tempi molto brevi), la stessa build viene automaticamente rilasciata anche in produzione, il tutto in una manciata di minuti e con il semplice click di un tasto.

Il fatto che questo processo sia quasi totalmente automatizzato ci permette di rilasciare continuamente (spesso più volte al giorno) senza dover sacrificare altre attività e soprattutto senza dover programmare interruzioni di servizio.

Grazie all’infrastruttura di CI e CD, Slope viene aggiornato con più di 200 rilasci all’anno.

Ciascun rilascio consiste nell’aggiunta di nuove funzionalità, ottimizzazioni, semplificazioni grafiche e interventi di miglioramento alla piattaforma senza causare nessun tipo di interruzione o rallentamento agli utenti che utilizzano il software.

Se siete curiosi di capire di più le strategie di sviluppo software Slope vi suggeriamo di leggere:

• Fondamenti dell’architettura Slope: qualità ed usabilità del software
• Sveliamo gli strumenti software scelti per creare l’architettura alla base della piattaforma Slope

Per maggiori informazioni su Slope e sulle funzionalità del software non esitate a contattarci!