Università degli studi di Padova Dipartimento di Matematica
Corso di Laurea in Informatica
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda mat. 599260
Relatore:
Prof. Tullio Vardanega
Tutor aziendale:
Federico Dal Maso
Questa relazione descrive nel dettaglio le 320 ore di lavoro previste alla fine del terzo anno del corso di Laurea in Informatica, anno accademico 2011/2012. L’azienda che mi ha ospitato si chiama Miriade ed ha sede in Thiene(VI), città dove risiedo.
Il documento fornisce una notazione particolare per voci di glossario e riferimenti, rispet- tivamente rappresentati tramite [Voce glossario]g e [Riferimento esterno]rif.
Ringraziamenti
Ringrazio la mia famiglia per avermi permesso di completare il corso di studi.
Ringrazio il Prof. Vardanega per avermi affiancato nella redazione di questo documento con molta pazienza e soprattutto per avermi istruito nel migliore dei modi.
Ringrazio il tutor aziendale Federico Dal Maso per l’ottimo argomento di stage e il sup- porto ricevuto durante i mesi di lavoro.
Ringrazio la mia fidanzata Chiara per avermi dato un ottimo motivo di proseguire con il massimo della volontà.
Ringrazio i miei amici di una vita, le loro famiglie e tutti quelli che hanno in qualche modo contribuito a farmi vivere questa fantastica esperienza.
Tabella dei contenuti
Dominio applicativo! 6
...
1.1 - Contesto aziendale! 6
...
1.2 - Spiderplan! 7
...
1.3 - Processi interni! 7
...
1.4 - Strumenti! 11
...
1.5 - Spiderplan è software as a service! 11
...
1.6 - Cloud computing! 11
...
1.7 - Continuous delivery ! 13
...
1.9 - Sviluppatori e Sistemisti! 15
Motivazioni, vincoli ed obiettivi! 17
...
2.1 - Architettura precedente! 17
...
2.2 - Problemi riscontrati con l’implementazione originale! 21 ...
2.3 - Conseguenze su processi e attività aziendali e sul modello di ciclo di vita! 24 ...
2.4 - Premesse all’implementazione tecnica! 27
Problema e risoluzione! 29
...
3.1 - Pianificazione! 29
...
3.3 - Progettazione architetturale! 38
...
3.4 - Progettazione di dettaglio! 43
...
3.5 - Dettagli implementativi! 46
...
3.5 - Risultati ottenuti! 54
Valutazione retrospettiva! 58
...
4.1 - Copertura dei requisiti! 58
...
4.2 - Competenze acquisite tramite lo stage! 60
...
4.3 - Gestione di richieste frequenti! 61
...
4.4 - Potenziale nuovo progetto! 62
...
4.5 - Conoscenze mancanti allo svolgimento dello stage! 63
...
4.6 - Proposte di insegnamenti per il corso di studio! 64
Glossario! 65
Riferimenti! 69
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 5 di 71
Dominio applicativo
1.1 - Contesto aziendale
L’azienda
Miriade è una media impresa del settore ICT con sede a Thiene (VI), composta di circa una trentina di persone.
L’azienda offre un ambiente giovane e moderno, caratterizzato da ricambi frequenti e continuo rinnovamento influenzato anche dal tipo di stage che io ho effettuato.
Il cliente tipo di Miriade è l’azienda medio-grande che opera a livello internazionale e necessita essere seguita da personale specializzato. L’azienda offre al cliente:
• Creazione e manutenzione dell’architettura di sistemi informatici
• Gestione e ottimizzazione di database
1
• Sviluppo di applicativi web, mobile e desktop
• Gestione di servizi tramite cloud computing
Oltre a ciò, sono organizzati eventi tecnici formativi sulle principali tematiche trattate dall’azienda, ai quali possono partecipare tutti le persone che hanno interesse o contatti aziendali.
Il mio stage è stato svolto nel settore sviluppo assieme a Federico Dal Maso, Lorenzo De Nardo e Andrea Pretto. Il tema principale è l’automazione delle attività ricorrenti e talvolta rischiose legate al progetto Spiderplan, con obiettivo la costruzione di un siste- ma adeguato all’offerta e al mantenimento di prodotti del tipo [Software as a service]g.
1.2 - Spiderplan
Project management
Il prodotto è un gestore di progetti. Esso è distribuito secon- do il modello Software as a Service e utilizzato tramite un web browser. I clienti sono aziende e ottengono un account che è associato ad un ambiente privato e condiviso tra più persone. La peculiarità del software risiede nella collabora- zione della gestione di progetti a livello aziendale, sul modello [Google Apps]g, tramite web browser.
Spiderplan è composto di moduli, si appoggia alla tecnologia [Java]g ed è pensato per essere distribuito tramite il web server [Tomcat]g.
Non si ritengono utili maggiori informazioni tecniche legate al software stesso per la comprensione del tema principale dello stage.
1.3 - Processi interni
Non esiste per Spiderplan un vero e proprio modello di ciclo di vita. Esistono invece del- le attività ricorrenti che ricordano il modello [agile]g: di queste vengono menzionate quelle che maggiormente hanno influenzato l’attività di stage.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 7 di 71
Attività di acquisizione nuove funzionalità
Essendo il proponente del progetto l’azienda stessa, le nuove funzionalità vengono pro- poste e concepite da personale interno, soprattutto commerciale, che lavorando a stret- to contatto con il cliente riceve continuamente stimoli dall’esterno.
Non esiste ancora un processo standard di accettazione: le proposte arrivano al team di sviluppo che analizza rapidamente la fattibilità e quantifica il tempo necessario. Se l’im- plementazione della funzionalità viene ritenuta valida, allora il team assegna il lavoro necessario a chi di dovere.
L’integrazione di funzionalità particolari o potenzialmente dannose all’integrazione è ef- fettuata tramite la funzionalità di [branching]g del controllo di versione, che garantisce la stabilità del ramo principale.
Attività di progettazione
Il team di sviluppo lavora in un ambiente fisico condiviso. Il fatto di essere fisicamente vicini implica che la maggior parte delle decisioni vengono prese informalmente tra i membri del team.
Non esistono veri e propri ruoli tra le persone coinvolte, esistono invece categorie di at- tività logicamente correlate che vengono assegnate a persone. La produzione docu- mentale è interna e serve a tenere traccia di quanto è stato deciso.
Un’altro tipo di documentazione strettamente tecnica è prodotta dallo strumento [Java- doc]g.
Attività di sviluppo
A seconda della tipologia e dimensione della nuova funzionalità viene svolta una proget- tazione adeguata. Se la progettazione coinvolge il lavoro di più di una persona allora la produzione di essa è condivisa; altrimenti lo sviluppatore è autonomo.
Nel momento in cui si rende necessaria la codifica lo sviluppatore agisce come di segui- to:
• Genera sulla sua postazione un’istanza del progetto integrato e funzionante (di norma già esistente).
• Codifica le modifiche come da progettazione.
• Integra le modifiche verificando il funzionamento
• Scrive i test necessari a quanto ha modificato
• Verifica il funzionamento dei test
• Esegue l’integrazione del nuovo codice sul controllo di versione
Fig. 1.1: diagramma di flusso dell’attività di sviluppo
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 9 di 71
Attività di integrazione nuove funzionalità
L’ultima versione ufficiale del codice sorgente risiede all’interno del branch “master” del repository spiderplan. Per garantire il funzionamento continuo del progetto, l’integrazio- ne delle nuove funzionalità di un certo rilievo richiede l’esito positivo dei seguenti:
1. Fusione dell’ultimo codice disponibile sul branch “master” (nel frattempo verosimil- mente modificato da altri) nel branch di sviluppo della nuova funzionalità e verifica compilazione e test.
2. Produzione artefatto e verifica dell’integrazione.
A questo punto è possibile importare le proprie modifiche nel branch “master”
1.4 - Strumenti
Aziendali
L’ambiente ufficiale aziendale per lo sviluppo di Spiderplan è [Eclipse]g. La comunica- zione informale tra i membri coinvolti è sulla chat di Google. La generazione condivisa di documenti è su Google Docs. Il controllo di versione è affidato a [Git]g. Il client per la connessione remota alla rete aziendale è openvpn.
Personali
Editor di testo semplice TextMate. SourceTree per interfaccia grafica Git. [Github]g per l’esecuzione di un [fork]g della libreria open source aws-tasks.
1.5 - Spiderplan è software as a service
L’esplosione delle tecnologie web durante la fine gli anni novanta ha profondamente modificato il modo di distribuire il software.
Al consumatore non è più richiesto l’acquisto di un supporto fisico contenente il software e l’installazione e mantenimento presso macchine di proprietà. Si offre invece tramite internet la possibilità di usufruire di una piattaforma centralizzata e mantenuta dal forni- tore, con chiari vantaggi in termini di costi e tempo per entrambe le parti.
Il modo più semplice e diventato ormai standard è la distribuzione del software tramite un web browser.
1.6 - Cloud computing
Per le stesse ragioni che hanno portato alla creazione delle filiere riguardo alla creazio- ne, distribuzione e manutenzione di prodotti classici, con il progredire degli strumenti si sono identificati nuovi ruoli nel settore software: il fornitore di infrastruttura e il fornitore
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 11 di 71
di piattaforma. Sempre di più queste figure vengono divise a causa della sempre cre- scente complessità di gestione.
La gestione dell’infrastruttura riguarda la fisica delle macchine (il mantenimento di un [datacenter]g) e l’offerta di un interfaccia consona al fornitore di piattaforma (la [virtua- lizzazione dell’infrastruttura]g).
La gestione della piattaforma riguarda l’architettura del software: progettazione, svilup- po e mantenimento, offrendo al consumatore il prodotto finale ovvero il software vero e proprio.
In commercio non esiste una netta divisione tra le figure: si possono trovare fornitori che offrono servizi a diversi livelli di astrazione. [Amazon Web Services]g è uno dei fornitori di infrastruttura: offre la gestione virtualizzata di server, reti, bilanciatori di carico e molto altro. Il fatto di affidare a terzi la gestione dell'infrastruttura, oltre ai vantaggi descritti in precedenza, può eventualmente offrire una potenza di elaborazione non ottenibile in una media struttura come Miriade.
La scelta è stata quindi di comprare il servizio Amazon ed utilizzare l'interfaccia API che offre per la completa gestione del software. Il paradigma “as a service” sta quindi a si- gnificare l’offerta di un’interfaccia ad uso del livello superiore della filiera.
Fig. 1.3: filiera del software online
1.7 - Continuous delivery
Come precedentemente anticipato, dal punto di vista dell’utente, la manutenzione al software è trasparente: l’utente vede direttamente le nuove funzionalità integrate e fun- zionanti.
La questione dell’aggiornamento è di fondamentale importanza sia per il consumatore che per il fornitore del software; il consumatore non vorrà vedere il prodotto stravolto, il fornitore non vorrà esporsi a grandi rischi nel modificare quello che già esiste.
Continuous delivery è un termine anglosassone di recente adozione, che letteralmente significa “consegna continua”, e settorialmente identifica il fornitore che aggiorna il pro- dotto regolarmente su periodi di tempo medio-corti (bisettimanali, settimanali o anche minori).
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 13 di 71
Per ottenere questo tipo di risutati è necessaria la totale automazione della [pipeline di deploy]g del prodotto che, nel caso dei software as a service, deve inoltre rispettare gli utenti che potrebbero dover usare il prodotto durante l’aggiornamento.
Fig. 1.4: continuous delivery
L’automazione delle operazioni inoltre garantisce un livello di affidabilità molto maggiore dell’esecuzione manuale. La sua implementazione fa parte a tutti gli effetti della base di codice, va inclusa nel controllo di versione, mantenuta e continuamente migliorata.
1.8 - Automazione delle attività
Tuttle le attività ricorrenti legate allo sviluppo e al mantenimento del progetto Spiderplan (dette operazioni e descritte dettagliatamente nel capitolo 2), sono automatizzate usan- do [Apache Ant]g: un [linguaggio di dominio]g basato su java ed xml che permette la definizione di tutte le procedure necessarie. Attorno a questo strumento sono state poi svolte le attività descritte esaustivamente nei capitoli successivi.
Apache Ant supporta librerie esterne tra le quali in quelle usate:
• [Apache Ivy]g (Gestione dipendenze)
• [Ant-contrib]g (Supporto a cicli ed espressioni regolari)
• Aws-tasks (Supporto a procedure legate al cloud di Amazon, sviluppato in parte du- rante lo stage)
1.9 - Sviluppatori e Sistemisti
La prima conseguenza diretta dell’utilizzo del cloud computing è la deresponsabilizza- zione dal mantenimento fisico di macchine. Il paradigma software as a service e i mo- delli agili abbattono i rischi legati alla manutenzione del software tramite piccole, fre- quenti e poco rischiose modifiche.
Detto questo, la tradizionale suddivisione del personale IT tra sviluppatori e sistemisti non ha più motivo di esistere in quanto, tramite il cloud computing, anche l’infrastruttura viene trattata esattamente come un’interfaccia esterna gestibile a livello di codice sor- gente.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 15 di 71
Il personale che lavora con il cloud deve necessariamente avere un’ottima conoscenza dell’uno e dell’altro mondo. All’estero la figura è denominata “DevOps”, acronimo di [de- velopement and operations]g.
Fig. 1.5: developement and operations
Motivazioni, vincoli ed obiettivi
2.1 - Architettura precedente
La sezione descrive alcuni dettagli di implementazione necessari alla comprensione dei concetti successivamente forniti, ovvero le motivazioni aziendali concrete che hanno portato allo stage e alla volontà di automatizzare le operazioni ricorrenti come accenna- to nel capitolo precedente.
Moduli Spiderplan e organizzazione dei sorgenti
Il codice sorgente risiede su un server interno che gestisce gli accessi in lettura/scrittu- ra. La [working directory]g contiene i moduli tramite cartelle denominate spider- plan-nome_modulo, uno dei quali è dedicato allo scripting Ant necessario alle opera- zioni multi-modulo.
La figura 2.1 mostra la visione della radice e in particolare la struttura del modulo spi- derplan-web, che in questa sezione viene usato come esempio. La struttura dei file ne- cessari alla generazione dell’artefatto è legata al linguaggio Java ed è coerente con il
1
[layout standard Maven]rif, al quale il lettore si riferisca per eventuali maggiori appro- fondimenti.
Fig. 2.1: struttura della working directory
All’interno del modulo sono inoltre visibili due particolari file build.xml ed ivy.xml che sono utilizzati da Ant, si applicano alla cartella nella quale sono inclusi e rispettivamente contengono lo scripting necessario all’automazione delle operazioni e la dichiarazione delle dipendenze del modulo corrente. Questi due file sono di grande importanza in quanto presenti in ogni modulo sul quale si lavorerà e manterranno lo stesso significato per tutta la lettura del documento.
A scopo illustrativo è visualizzabile il contenuto del file build.xml situato nella cartella del modulo spiderplan-build. Come anticipato, il modulo è fittizio ed è semplicemente un contenitore per l’esecuzione di operazioni su più moduli.
Maggiori dettagli riguardo Apache Ant
Questa sezione fornisce una comprensione basilare del funzionamento di Ant. Esso è basato su xml, dove i [tag]g identificano una generica operazione od oggetto e gli attri- buti identificano parametri.
Con riferimento al file visibile in figura 2.1, si descrivono due tra i più importanti elementi distintivi di uno script interpretato dal sofware: i tag project e target.
Il tag project identifica il punto di partenza di ogni progetto. Il flusso standard di esecu- zione degli script è il posizionamento di una console in una cartella contenente un do- cumento XML denominato build che dichiara come radice un tag project, e il lancio del comando ant. Successivamente al lancio viene istanziato un ambiente indipendente di esecuzione, all’interno del quale sono disponibili una serie di valori non modificabili de- nominate property.
Fig. 2.2: esempio di target
Il tag target visibile in figura 2.2 identifica una procedura eseguibile. Il suo attributo de- pends definisce i riferimenti ad altri target divisi da virgola, i quali vengono indipenden- temente eseguiti prima della corrente.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 19 di 71
È interessante notare che non è stata prevista nativamente l’inclusione di parametri nel- le chiamate: questo fatto, insieme alla immutabilità delle property, suggerisce la natura batch del linguaggio, cioè la semplice esecuzione sequenziale di procedure non para- metrizzabili, con evidenti limiti nell’implementazione di sistemi complessi.
Implementazione originale
L’automazione delle operazioni presente al mio arrivo era legata alle necessità quoti- diane derivanti dallo sviluppo e verifica del prodotto.
In questo senso erano presenti gli script che permettevano la compilazione del singolo modulo e la pulizia della working directory da eventuali file temporanei. Come intuibile in figura 2.1, le uniche operazioni permesse dall’integrazione erano la compilazione e la pulizia sequenziale dei moduli. Tutte le restanti operazioni erano eseguite manualmen- te.
Maggiori dettagli riguardo Apache Ivy
Fig. 2.3: Esempio di dichiarazione delle dipendenze di un modulo tramite il file ivy.xml
Apache Ivy è una libreria che fornisce ad Ant alcune funzionalità utili per la gestione degli asset necessari all’esecuzione delle operazioni. Il concetto più importante della libreria è la possibilità di rendere automatiche le attività di [risoluzione]g, download e pubblicazione di [artefatti]g, nella fattispecie dipendenze e prodotti dei moduli e dell’in- tegrazione, con la possibilità di configurare i [repository]g sui quali operare.
2.2 - Problemi riscontrati con l’implementazione originale
L’implementazione descritta precedentemente ha messo in luce una serie di problema- tiche descritte nelle sezioni successive, che rendono al lettore chiare le motivazioni concrete di studio del problema.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 21 di 71
Risoluzione dipendenze transitive
Fig. 2.4: transitività delle dipendenze
I moduli spiderplan fanno uso estensivo di librerie. Ogni libreria a sua volta può dichia- rare dipendenze da altre librerie. Le librerie sono ospitate da server pubblici che non garantiscono la risoluzione trasitiva delle dipendenze; in altre parole possono esistere librerie che dichiarano dipendenze non risolvibili sul repository che ha ricevuto la richie- sta.
La risoluzione immediata di questa problematica è stata l’inclusione manuale delle libre- rie incriminate all’interno del filesystem tracciato dal controllo di versione. Questa prati- ca si è rivelata un [antipattern]g, gravando sulla complessità di attività ricorrenti, per esempio nella necessità di mantenimento manuale della cartella sulla quale le librerie vengono riposte.
Riguardo all’attività di deploy
L’attività di deploy richiede un elevato numero di operazioni da eseguire sulle macchine coinvolte. Le configurazioni dell’ambiente spesso variano da una versione all’altra e si è rivelato critico il fatto di poterle facilmente testare. Durante le fasi di sviluppo si è valuta- ta molto importante la libertà dello sviluppatore di istanziare velocemente nuovi ambienti
e copie di ambienti esistenti per facilitare le operazioni di [debug]g o a generare un pro- totipo “al volo” da poter mostrare ai clienti.
Dipendenze da tecnologie
Alcuni moduli spiderplan necessitano di software esterni per la compilazione. La risolu- zione di errori dipendenti da software esterni si è rivelata un’attività dispendiosa e dalla quale non si ricava nessun tipo di valore aggiunto per il software.
Difficoltà di misura stabilità build
Il modello di ciclo di vita e l’attività di rilascio di una nuova versione del prodotto ha visto necessaria una misurazione costante della stabilità del progetto.
Accoppiamento tra configurazioni e sorgenti
Il codice sorgente dei moduli spesso include configurazioni necessarie al funzionamen- to dell’ambiente ospitante. Questo è un antipattern in quanto intralcia la generazione automatica di istanze su macchine potenzialmente configurate diversamente.
Livello di rischio upgrade sistema in produzione
Le precedenti difficoltà intralciano l’upgrade del sistema in produzione rendendolo quasi sicuramente fallimentare sul primo tentativo, con ovvie ripercussioni sull’esperienza d’uso del consumatore.
Il test dell’upgrade deve essere necessariamente effettuato su un ambiente di prova che deve essere il più simile possibile all’ambiente in produzione, verificato ed even- tualmente migrato. La generazione dell’ambiente di prova soffre di tutte le problemati- che precedentemente mezionate.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 23 di 71
2.3 - Conseguenze su processi e attività aziendali e sul modello di ciclo di vita
Con riferimento al capitolo 1, il lettore intuisce che le problematiche menzionate rendo- no difficile e aleatoria la consegna continua del prodotto. In questa sezione si descrivo- no i processi aziendali che dovrebbero poter essere facilmente messi in pratica (deri- vanti da requisiti di tipo commerciale) e i punti nevralgici nei quali si è agito durante lo stage per rendere più affidabile il raggiungimento dell’obiettivo.
Attività di integrazione nuovo codice sorgente
Riprendendo quanto anticipato nel capitolo 1, l’attività di integrazione di nuovo codice sorgente si rende necessaria ogniqualvolta uno sviluppatore ha correttamente concluso l’attività di codifica di una univoca modifica sulla base di codice pre-esistente.
Nell’ottica di consegna continua, la verifica e validazione di una modifica è un’attività fondamentale in quanto la probabilità di introdurre difetti nel programma è molto alta. Se si dovesse verificare questa eventualità, le ripercussioni sul lavoro del gruppo sarebbe- ro notevoli e si tradurrebbero in un ritardo che potrebbe non essere compatibile con le consegne prefissate a calendario: va quindi minimizzata la probabilità che ciò avvenga.
Si rende quindi fondamentale la definizione di un’attività che dia un buon livello di sicu- rezza riguardo alla bontà del nuovo codice inserito nel repository condiviso. In questo senso vanno definite precise regole di inclusione di test di unità, di integrazione e fun- zionali (non incluse in questo documento in quanto non facenti parte delle responsabili- tà a me assegnate), e il processo di accettazione di una modifica, che svolge in auto- nomia lo sviluppatore, e che comprende in particolare l’esecuzione dell’operazione di deploy su un ambiente Spiderplan esistente.
E’ quindi desiderabile che tale attività sia automatizzata al massimo livello possibile per ottimizzarne i tempi e la qualità di esecuzione, nella prospettiva di ottenere la libertà di eseguire piccole, affidabili e frequenti modifiche senza dover incorrere in laboriose atti-
Processo di creazione e clonazione ambiente
Il processo di creazione di un ambiente è istanziato da numerosi altri processi e preve- de un alto numero di attività che devono essere necessariamente svolte per ottenere un nuovo ambiente “pulito” che permetta l’operazione di deploy di una certa versione del prodotto. Non è esagerata la previsione di poter impiegare uno o più giorni lavorativi per generare ambienti pronti ad ospitare software di grandi dimensioni, ed è per questo mo- tivo che spesso il processo non viene istanziato con motivazione “se funziona di qua, probabilmente funziona anche di là” (verificatasi poi quasi sempre falsa).
Questo processo quindi, nonostante la sua frequenza non sia molto elevata, si rivela essere chiave nel controllo della qualità del software, e la sua automazione regala quin- di grandi vantaggi in questo senso.
I processi chiave che necessitano l’istanziazione di ambienti sono:
Processi e attività Frequenza
Preparazione workstation Bassa
Branching Media
Validazione release candidate Media
Creazione prototipo “al volo” Alta
Tab. 2.4: Frequenze delle operazioni più comuni
Attività di verifica di una release candidate
Non è raro che si verifichino comportamenti non previsti durante l’esecuzione dell’ope- razione di deploy su un ambiente di produzione. Anche ipotizzando un aggiornamento di successo in un ambiente di prova, esistono differenze legate ai dati esistenti e alle configurazioni usate in produzione.
L’attività di verifica di una release candidate prevede l’esecuzione dell’operazione di de- ploy della versione ritenuta definitiva di un aggiornamento su un’ambiente di test quan- to più simile a quello in produzione (comprendendo quindi dati, middleware, hardware e configurazioni), in modo di poter verificare a fondo quanto poi verrà fatto sull’ambiente
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 25 di 71
reale di produzione. È inoltre buona pratica evitare la modifica manuale di una qualsiasi configurazione o dato in ambiente di produzione per mantenere la totale replicabilità dello stato del software a fini di debug.
Tutto ciò, sebbene raccomandabile anche nelle tipologie di software tradizionale, si rende assolutamente necessario nell’ottica della consegna continua, con obiettivo il raggiungimento di un’attività affidabile e testata che permetta di effettuare con un ottimo livello di tranquillità il processo principe di questo tipo di mantenimento del prodotto: il rilascio di nuovo software in ambiente di produzione.
Processo di rilascio in produzione nuova versione
Come anticipato, il processo di rilascio identifica l’attività più importante di ogni software house. Le conseguenze di quello che accade durante l’esecuzione ricadono per feno- meni di causa-effetto su tutti i reparti aziendali, siano esse positive o negative. Si rivela quindi di assoluta priorità il controllo di quanto accade prima, durante e dopo questo im- portante evento.
PRE-ESECUZIONE
Prima del rilascio in produzione di un software, è necessario verificare con successo l’esecuzione dell’attività di verifica della release candidate che si intende usare per l’ag- giornamento dei sistemi in produzione.
ESECUZIONE
La stessa strategia utilizzata per migliorare l’affidabilità degli altri processi ed attività viene quindi applicata anche al processo di rilascio di una nuova versione, automatiz- zando quindi tutte le operazioni necessarie a portarlo a termine. È importante ricordare che anche le modifiche a dati o configurazioni devono essere automatizzata per garan- tirne la loro replicabilità.
POST-ESECUZIONE
La sicurezza di buona riuscita di un aggiornamento non può essere garantita in nessun caso. Per questo motivo si rende necessaria la gestione del rischio di un fallimento, con fine la minimizzazione del danno.
Nel caso di Spiderplan, si intende gestire il semplice caso in cui la versione precedente del software, le configurazioni ed i dati vengano ripristinati allo stato precedente, ovvia- mente in maniera automatica.
Il processo è indipendente in quanto dovrebbe poter essere istanziato in maniera indi- pendente dal processo di rilascio. Il rilascio dovrebbe quindi prendersi carico di prepara- re tutto quello si riveli necessario, ovviamente in maniera automatica.
2.4 - Premesse all’implementazione tecnica
Una buona comprensione del problema commerciale costituisce fondamentale punto di partenza e giustificazione alla comprensione dell’implementazione tecnica della solu- zione. Questo capitolo ha tentato di mettere in luce prima le difficoltà e poi i processi nei quali esse si verificano con più importanza.
Impatto sul modello di ciclo di vita
Come descritto nel capitolo 1, il modello software as a service nasce in concomitanza del successo delle tecnologie internet e, in particolare ma non solo, il web. Il nocciolo della questione è quindi la gestione della fornitura in modo centralizzato e remoto.
Non per caso le tecniche di continuous delivery del software sono nate e si sono svilup- pate con la precisa necessità di semplificare la gestione di questo tipo di fornitura. In particolar modo a causa della enorme crescita di responsabilità derivante dall’ accre- sciuto numero di clienti coinvolti.
Il modello di ciclo di vita del prodotto assume quindi ancora più importanza, in quanto influenza tempi e modi di progettazione, analisi, codifica e rilascio, che necessariamen- te si devono sposare con le necessità commerciali derivanti dal modello software as a service.
In questo senso le metodologie agili si rivelano adeguate a rispondere rapidamente ai piccoli cambiamenti dei rilasci frequenti (motivati in precedenza). C’è da dire che quasi sempre nelle medio-piccole realtà aziendali italiane, il concetto di modello di ciclo di vita non è sempre ben chiaro, e va adattato per quanto possibile alle caratteristiche azien- dali e alle nuove necessità commerciali.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 27 di 71
Problema e risoluzione
3.1 - Pianificazione
Definizione del piano di lavoro
Definite le premesse il progetto di stage indica sei obiettivi principali fissati dal tutor aziendale, riportati in questo documento senza apportare modifiche:
1. Ingegnerizzare il sistema di [build]g dei singoli moduli e dell’integrazione complessi- va. L’output finale dovrebbe essere uno script in grado di eseguire il tutto (dal [chec- kout]g git alla generazione dei moduli finali alla generazione dei report dei test) con un solo run da linea di comando. Questa parte al 70% è già implementata
2. Si vuole implementare un repository interno Ivy, capire pro e contro dell’approccio (soprattutto la chiusura transitiva delle dipendenze) e stendere delle linee guida per gli sviluppatori soprattutto per lo sviluppo di progetti modulari in ambiente Eclipse/
Ivy/Ant. Ivy è giù usato in 3 moduli. Il repository interno non esiste.
1
3. Configurare un server [Jenkins]g e configurare il sistema affinchè esegua il build complessivo degli artefatti automaticamente tramite un trigger sui commit del server git interno all’azienda. Stendere le linee guida per facilitare l’ingegnerizzazione simi- le in altri progetti futuri.
4. Versionamento della infrastruttura Amazon. Si vuole codificare via CloudFormation e script al contorno l’intera infrastruttura del prodotto finale. Attualmente essa è confi- gurata da console Amazon.
5. Deploy automatico completo dell’infrastruttura di quality direttamente da Jenkins. In questo step il sistema dovrebbe essere in grado di:
• Eseguire un checkout di una certa versione da git
• Compilare tutti i moduli
• Generare gli script di upgrade dei database
• Recuperare o eseguire un backup di alcuni database in produzione
• Spegnere la vecchia infrastruttura di quality
• Rigenerare via CloudFormation un’intera infrastruttura Spiderplan.
• Popolare il database tramite restore dei backup di produzione.
• Offuscare i dati (per questioni di privacy sui backup)
• Eseguire l’upgrade dei database
• Eseguire i test di validazione dell’upgrade.
• Avviare l’installazione di quality
Lo scopo di questo obiettivo è validare un sistema che sia in grado di eseguire un upgrade di test all’ultima versione del prodotto, partendo dal sistema attualmente in produzione.
6. Ingegnerizzare un sistema in grado di eseguire un upgrade, a comando, del sistema di produzione a una nuova versione (usualmente già testata in ambiente di quality assurance). Pensare ad un sistema di rollback all’ultima versione stabile.
Piano settimanale di lavoro
È stato definito un piano settimanale di lavoro dal tutor interno, del quale settimana per settimana fornisco la programmazione e descrivo le attività caratterizzanti.
Settimana 1
Attività Durata prevista
(in giorni)
Studio individuale Ant 0.5
Studio individuale Ivy 1
Studio individuale Amazon AWS 1.5
Studio individuale Continuous Delivery (materiale cartaceo) 2
Tab 3.1: attività della prima settimana di stage
Settimana 2
Attività Durata prevista
(in giorni)
Setup strumenti e configurazioni 0.5
Studio script esistenti e progettazione soluzioni 4
Discussione con team sviluppo 0.5
Tab 3.2: attività della seconda settimana di stage
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 31 di 71
Settimana 3
Attività Durata prevista
(in giorni) Implementazione soluzioni lato Ant accordate al termine della pre-
cedente settimana 4
Configurazione di un repository Ivy su un server interno 1
Tab 3.3: attività della terza settimana di stage
Settimana 4
Attività Durata prevista
(in giorni) Configurazione dei moduli Ivy e documentazione delle problemati-
che emerse 2
Risoluzione problematiche 2
Stesura documentazione 1
Tab 3.4: attività della quarta settimana di stage
Settimana 5
Attività Durata prevista
(in giorni) Installazione di un server Jenkins interno, completo di integrazione
a git e sua documentazione 1
Definizione target per Jenkins (con personale Miriade) e adattamen-
to script ant e trigger su git affinchè i moduli compilino da Jenkins 4 Documentazione dell’ingegnerizzazione effettuata in un’ottica di ri-
uso in altri progetti 1
Tab 3.5: attività della quita settimana di stage
Settimana 6
Attività Durata prevista
(in giorni)
Studio CloudFormation 0.5
Configurazione template server database PostgreSQL da script
CloudFormation 1.5
Configurazione template application server Tomcat/Apache da script
CloudFormation 1.5
Configurazione rete 0.5
Test script complessivo 0.5
Verifica settimanale e illustrazione a team di sviluppo delle attività
fatte e dei problemi emersi 0.5
Tab 3.6: attività della sesta settimana di stage
Settimana 7
Attività Durata prevista
(in giorni) Progettazione del flusso di lavoro da automatizzare 1 Automatizzazione del backup con supporto del nostro DBA 1
Sviluppo script di avvio e deployment 3
Tab 3.7: attività della settima settimana di stage
Settimana 8
Attività Durata prevista
(in giorni)
Margine di attività 4
Documentazione sistema 1
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 33 di 71
Tab 3.8: attività dell’ottava settimana di stage
Settimana 9
Attività Durata prevista
(in giorni) Modifica degli script dell’obiettivo per la realizzazione dell’obiettivo 5 3 Verifica finale con il team di sviluppo. Documentazione dell’attività 2
Tab 3.9: attività della nona settimana di stage
Modello di ciclo di vita del progetto di stage
Il progetto di stage è stato inizializzato su un ramo differente rispetto al ramo principale di sviluppo del progetto Spiderplan (anche a livello di codice sorgente); non sono inoltre state fissate [milestone]g riguardo alla consegna o alla effettiva necessità pratica della mia parte di progetto. Di fatto, Spiderplan era ancora un progetto interno, e per questo motivo ho avuto libertà di gestione individuale riguardo al modello di ciclo di vita da adottare.
La scelta che ho effettuato è stata quella di allinearmi al gruppo, ovvero tentare di ripro- durre i processi e le attività che ho visto in azienda applicandoli incrementando i prototi- pi che man mano venivano generati dal lavoro.
Durante tutta la durata del lavoro sono state quindi istanziate le seguenti attività e pro- cessi ( definiti secondo logica [bottom-up]g ):
INTEGRAZIONE FUNZIONALITÀ
L’attività di integrazione di una funzionalità o modifica è stata la più frequentemente istanziata durante tutta la durata del lavoro. La sua durata media è minore di una setti- mana lavorativa.
Fig. 3.10: attività di integrazione funzionalità
L’allineamento con il tutor aziendale riguardo all’implementazione della nuova funziona- lità ha dato quasi sempre esito positivo.
PROCESSO DI INCREMENTO PROTOTIPO
Il processo di incremento prototipo è legata agli obiettivi definiti preventivamente sul piano di lavoro: essi rappresentano un preciso aumento del prototipo precedente, carat- terizzato dal contenere un gruppo di funzionalità correlate, quasi sempre dipendenti una dall’altra e identificabili da un preciso requisito. La sua durata media è misurabile in set- timane.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 35 di 71
Fig. 3.11: processo di incremento prototipo
Il processo permette la progettazione di un singolo incremento, rendendo affidabile l’esecuzione dell’attività di integrazione funzionalità. Per quanto riguarda l’ordine di im- plementazione, si è tenuto conto informalmente delle dipendenze in entrata di ognuna di esse.
L’allineamento del team di sviluppo è una riunione svolta in azienda dove si condivide quanto fatto e si danno informazioni riguardanti all’eventuale possibilità di riutilizzo della soluzione in altri contesti.
Il completamento del progetto è stato quindi raggiunto, a partire da quanto già esisteva, tramite l’esecuzione del processo di incremento prototipo per ogni requisito presente nella definizione ( sia esso stato estratto dal piano di lavoro o inserito in corso d’opera ).
3.2 - Requisiti estratti dal piano di lavoro
La sezione descrive formalmente gli obiettivi estratti dal piano di lavoro, fornito dal tutor aziendale Federico Dal Maso. Per il riferimento di un requisito all’interno del documento verranno utilizzate delle etichette autoesplicative:
➤ obb # Requisito obbligatorio
➤ des # Requisito desiderabile
➤ opz # Requisito opzionale
Tab. 3.12: legenda di lettura tabelle requisiti
Requisiti obbligatori
# Descrizione
1 La risoluzione delle dipendenze di ogni modulo è automatica 2 La compilazione di ogni modulo è automatica
3 La generazione di documentazione Javadoc di ogni modulo è automatica 4 L’esecuzione dei test di ogni modulo è automatica
5 La generazione dell’archivio war di ogni modulo è automatica 6 Le dipendenze devono garantire la loro chiusura transitiva
7 Deve esistere un repository interno che supporti l’archiviazione degli artefatti 8 Deve esistere un server di continuous integration Jenkins
9 Il server Jenkins deve reagire ad ogni commit sul repository git eseguendo automaticamen- te le build dei moduli
Tab. 3.13: requisiti obbligatori
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 37 di 71
Requisiti desiderabili
# Descrizione
1 L’infrastruttura di quality deve essere codificata tramite Amazon CloudFormation 2 L’operazione di deploy deve essere eseguita automaticamente da Jenkins
Fig. 3.14: requisiti desiderabili
Requisiti opzionali
# Descrizione
1 L’operazione di upgrade dell’ambiente di produzione deve essere automatizzata e testabile in ambiente di quality
2 L’operazione di rollback del sistema di produzione deve essere automatizzato
Fig. 3.15: requisiti opzionali
3.3 - Progettazione architetturale
La progettazione architetturale ha subito alcune modifiche in corso d’opera. Nel presen- te documento è inclusa la versione definitiva.
Come anticipato nel capitolo 1, la costruzione di un sistema adatto al raggiungimento degli obiettivi definiti prevede la collaborazione di varie tipologie di componenti hardwa- re e software, necessariamente guidati dal linguaggio di scripting Ant. Le componenti offrono interfacce di varia natura fruibili tramite diversi protocolli di comunicazione, l’im- plementazione dei quali sarà ignorata a questo punto del documento per facilitare la let- tura.
Visto il tentativo fallimentare di rendere adatto all’inclusione un diagramma formale, ho deciso di descrivere una ad una le componenti coinvolte, a partire da un diagramma in- troduttivo che aiuti l’intuizione del lettore. I riferimenti dai quali la progettazione è stata ispirata sono [The Twelve Factor App]rif e il libro [Continuous Delivery]rif.
La figura 3.3 semplifica e sintetizza il flusso delle operazioni sui componenti di una ope- razione di deploy.
Fig. 3.16: diagramma componenti coinvolte nell’operazione di deploy
Come visibile in figura 3.3 il mantenimento automatico di Spiderplan ha reso necessaria la separazione logica delle parti necessarie ad un’ambiente in dati, configurazioni, hardware e prodotto. Esse sono gestite da un’istanza attiva dell’automazione di Spi- derplan (guidata dallo scripting Ant), che può essere istanziata su un qualsiasi compu- ter che abbia accesso a quanto necessario. Si procederà decrivendo una ad una le componenti.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 39 di 71
Controllo di versione
Nel repository del controllo di versione vengono mantenuti allo stesso modo i sorgenti dei moduli Spiderplan e dell’automazione Ant (è infatti definito preventivamente l’accop- piamento delle due entità).
La struttura modulare del progetto avrebbe imposto di mantenere diversi repository per diversi moduli, trattandoli poi allo stesso modo come dipendenze. È stato scelto invece di mantenere la struttura pre-esistente per facilitare l’integrazione del nuovo codice sor- gente.
Server delle configurazioni
Le configurazioni necessarie all’ambiente e al mettere in esecuzione i moduli possono essere considerate parametri dell’operazione di deploy. È buona norma non includerle negli artefatti per non accoppiarli con gli ambienti. Per questo motivo è stato implemen- tato un web server che espone un’interfaccia su protocollo HTTP che, dato il nome di un ambiente, permette il facile recupero delle configurazioni necessarie.
Nella pratica, il server definisce gli ambienti esistenti per il progetto, che vengono recu- perate ogni volta si rendano necessarie operazioni sull’ambiente. In figura 3.4 è visibile l’albero delle cartelle servite dal web server delle configurazioni.
Allo stesso modo dei sorgenti, anche le configurazioni sono state mantenute in un repo- sitory Git. La pubblicazione di nuove configurazioni è responsabilità di un minimo pro- getto Ant, situato all’interno del file /build.xml, che semplicemente copia quanto trova nella cartella corrente nel web server dove effettivamente le configurazioni sono dispo- nibili al pubblico. Il server è situato all’interno delle rete aziendale, unico luogo dal quale può effettivamente essere usato.
Sarebbe desiderabile che il server garantisse funzionalità aggiuntive, come accesso au- tenticato, ereditarietà tra definizioni di ambienti e controllo sui valori dei parametri (nel documento saranno evidenziate tali necessità), tuttavia è stato deciso di non forzare i tempi progettuali e concentrarsi sulla parte fondamentale del lavoro.
Ogni ambiente è identificato dal nome e contenuto di una cartella dopo la radice del webserver. Il progetto Ant incaricato di eseguire operazioni sull’ambiente necessita di precise configurazioni contestuali che deve reperire nel file ant.properties dell’ambiente in questione. In figura 3.4 è possibile vedere alcune configurazioni necessarie ad Ant per operare sull’ambiente denominato quality-miriade-internal. Come intuibile, l’am- biente è situato in un server di proprietà Miriade.
Fig. 3.17: esempio di file ant.properties per l’ambiente quality-miriade-internal
Il protocollo HTTP si è rivelato adatto all’implementazione di tale servizio: ogni configu- razione può infatti essere considerata una risorsa. Esiste la necessità di definire proce- dure standard che permettano la definizione di configurazioni di ambienti con le caratte- ristiche mezionate in precedenza (ereditarietà, controllo di accesso.. ).
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 41 di 71
Server degli artefatti
Il problema della risoluzione delle dipendenze ha messo in luce la necessità di garantir- ne la risoluzione transitiva tramite il mantenimento di un servizio. Esistendo molti pro- getti completi a livello commerciale per tale scopo, è stato scelto [Sonatype Nexus]rif (valutato anche [Apache Archiva]rif).
L’installazione di un server ha permesso in prima istanza la possibilità di garantire la ri- soluzione delle dipendenze che non venivano risolte automaticamente presso il [reposi- tory pubblico maven]rif. Tra le funzionalità fornite dal software è stata chiave la possibi- lità di generare repository virtuali: è stato possibile definire un unico endpoint sulle con- figurazioni Ivy.
Un repository virtuale espone all’esterno la stessa interfaccia di una normale. Nel mo- mento in cui viene ricevuta una richiesta, la ricerca viene moltiplicata e redirezionata su di una serie di repository configurabile.
Questa funzionalità ha quindi permesso di includere un repository speciale contenente le librerie incriminate, non correttamente reperite. Il servizio ha inoltre consentito il ca- ching delle richieste, riducendo quindi quasi del tutto il tempo necessario al reperimento ripetuto di librerie ricorrenti. Questo problema costituiva un blocco molto importante in Miriade, a causa della scarsa disponibilità di banda in azienda.
Il server Nexus, oltre al reperimento di artefatti, è stato molto utile nella pubblicazione delle prodotti delle build dei moduli spiderplan, rendendoli automaticamente reperibili, alla stessa maniera delle dipendenze, nell’implementazione del codice necessario al deploy del software.
È inoltre molto comodo il fatto di poter facilmente mantenere uno storico centralizzato delle build dei progetti.
Istanza di automazione
Per istanza di automazione si intende una entità software che deve contenere:
1. Il codice sorgente dei moduli sui quali si intende lavorare 2. Lo scripting necessario alle operazioni possibili
3. I dati e le configurazioni eventualmente necessarie
Per il progetto di automazione per Spiderplan, sono state estratte delle operazioni per la soddisfazione dei requisiti definiti in precedenza. La loro implementazione verrà descrit- ta nel capitolo successivo.
Questo tipo di approccio ha permesso di slegare il sistema dalla macchina dove esso sia effettivamente eseguito. Questa funzionalità è richiesta dal requisito ➤ obb 8 che prevede che alcune delle operazioni fossero eseguite da un server di continuous inte- gration.
La corretta inizializzazione dell’istanza di automazione contiene pre-requisiti, che nel progetto di stage venivano identificati da:
1. Presenza nella macchina di un’installazione funzionante del software Ant 2. Accesso al repository del codice sorgente
3. Accesso al server delle configurazioni 4. Accesso al server degli artefatti
5. Accesso all’interfaccia API dei servizi AWS (credenziali valide)
L’interfaccia offerta dall’istanza di automazione identificano di fatto tutte le operazioni automatizzate disponibili per il progetto.
3.4 - Progettazione di dettaglio
In questo capitolo verrà descritta la progettazione dello scripting dell’automazione delle operazioni, attività che ha coperto la maggior parte del tempo di lavoro durante lo stage.
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 43 di 71
Analisi dei casi d’uso per l’istanza di automazione
La definizione di precisi requisiti per l’interfaccia offerta dell’istanza di automazione ha previsto l’analisi di ulteriori casi d’uso estratti dal piano di lavoro.
Fig. 3.18: Caso d’uso 1 - Interfaccia dell’istanza di automazione
Gli unici due attori previsti dalla documentazione generata per il progetto sono gli svi- luppatori stessi e il server di continuous integration Jenkins. Di fatto i due attori usano la stessa interfaccia, ma sono stati differenziati in figura 3.5 per chiarezza descrittiva.
È plausibile considerare l’attore ‘Personale’ come un’estensione dell’attore ‘C.I. Server’, in quanto a livello implementativo il secondo usa solamente un sottoinsieme delle ope- razioni disponibili al primo. Nell’implementazione corrente, non è comunque prevista la definizione di limitazioni di esecuzione ( “C.I. Server” ha potenziale accesso a tutte le funzionalità disponibili a “Personale”).
Dettaglio delle operazioni sui moduli
Il dettaglio delle operazioni sui moduli è presente in tabella 3.6.
Operazioni sui moduli Operazioni sui moduli
Identificatore Descrizione
clean Riporta la cartella allo stato iniziale
build Compila il modulo generando quanto necessario alla pubblicazione resolve Esegue il retrieving delle dipendenze dichiarate
run-tests Esegue i test definiti e ne compila i report deploy Esegue il deployment del modulo
publish Pubblica la versione corrente sul repository configurato
Tab. 3.19: Operazioni sui moduli
L’implementazione delle operazioni di clean, build, resolve e run-tests, assieme alla de- finizione delle dipendenze ivy e all’installazione del servizio nexus, permette la soddi- sfazione dei requisiti ➤ obb [1-7].
Queste operazioni inoltre sono necessarie alla soddisfazione di tutti gli altri requisiti.
Dettaglio delle operazioni sull’integrazione
Il dettaglio delle operazioni sull’integrazione è presente in tabella 3.7.
Operazioni sull’integrazione Operazioni sull’integrazione
Identificatore Descrizione
build Esegue l’operazione di build su ogni modulo disponibile
clean Esegue l’operazione di clean su ogni modulo disponibile
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 45 di 71
Operazioni sull’integrazione Operazioni sull’integrazione
start Esegue il setup iniziale dell’istanza di automazione
prepare-deploy Prepara l’ambiente scelto per l’esecuzione del deploy
push-artifacts Esegue il deployment delle dipendenze dichiarate
Tab. 3.20: Operazioni sull’integrazione
Le operazioni sull’integrazione servono alla soddisfazione dei requisiti ➤ obb [8] e ➤ des [2]. Il server di continous integration infatti necessita di operare anche sull’ambiente di deploy e per farlo deve usare l’interfaccia dell’istanza di automazione.
Dettaglio delle operazioni sugli ambienti
Il dettaglio delle operazioni sugli ambienti è presente in tabella 3.8.
Operazioni sugli ambienti Operazioni sugli ambienti
Identificatore Descrizione
wake-environment Prepara i componenti hardware dell’ambiente selezionato
init-environment Esegue le inizializzazioni necessarie alle macchine
reset-database Riporta il database di un ambiente ad un preciso stato
Tab. 3.21: Operazioni sugli ambienti
3.5 - Dettagli implementativi
Questa sezione descrive nel dettaglio l’implementazione delle operazioni precedente- mente descritte. Il tutor ha previsto l’implementazione delle operazioni solamente sui sui
moduli web, db, protobuf e schemadaemon, in quanto gli altri erano in uno stato an- cora inconsistente.
Struttura del codice
Fig. 3.22: Radice del progetto Spiderplan
In figura 3.9 è possibile vedere la struttura dei sorgenti del progetto. Come anticipato, nel repository è presente il codice sorgente dei moduli e dell’automazione. I contenuti più significativi sono riassunti in tabella 3.10
Elemento Descrizione
/azironda.pem Private key per l’accesso API Amazon
/ant File con funzionalità trasversali destinati all’inclusione
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 47 di 71
Elemento Descrizione
/documentation Cartella di destinazione per la generazione automatica di documentazione per l’istanza di automazione
/utility Cartella di utilità per software, dati o altri elementi non riconducibili diretta- mente al progetto
/user.properties Configurazioni generali legate all’entità che genera l’istanza di automazione /ivysettings.xml Configurazione generale del modulo Ivy per la definizione dei [resolver]g Ivy
e le credenziali di accesso
Tab. 3.23: Radice del progetto Spiderplan
La descrizione procederà descrivendo le operazioni sui moduli, di più semplice com- prensione, per poi proseguire con quelle sull’integrazione ed infine le operazioni su am- bienti.
Definizione funzionalità trasversali
Grazie al buon grado di standardizzazione (seppure informale) della struttura dei modu- li, è stato possibile uniformare facilmente la struttura di alcune operazioni comuni e ri- correnti.
Queste funzionalità sono state incluse nel file /ant/common-targets.xml. All’interno di questo file è stata definita un’interfaccia che possa aiutare i moduli nel portare a termine obiettivi trasversali.
Questo approccio ha permesso di semplificare la definizione e manutenzione dello scripting per l’automazione dei moduli, riducendolo sostanzialmente alla gestione del target per la generazione dell’artefatto. Le eventuali specializzazioni necessarie sono state gestite tramite la definizione di alcune property su ogni modulo.
Le operazioni sui moduli clean, resolve, run-tests e deploy sono state gestite quindi in maniera centralizzata e descritte ad alto livello in tabella 3.11. In questa sezione del do- cumento, l’operazione di deploy viene semplificata in quanto descritta nel dettaglio suc- cessivamente.
Operazione Descrizione clean rimuove il contenuto della cartella /target
resolve Risolve le dipendenze dichiarate dal file ivy.xml sulla cartella definita nella pro- perty deps.lib
run-tests Esegue i test presenti all’interno della cartella definita nella property test.dir deploy Esegue il deployment dell’archivio war definito all’interno della property war.file publish Pubblica la versione corrente del modulo
Tab. 3.24: descrizioni dell’implementazione delle operazioni trasversali sui moduli
Dettaglio operazioni sul modulo
La struttura data dalla definizione di target comuni suggerisce un design [object-orien- ted]g, nel quale si considerano i moduli istanze di una classe base specializzata per il comportamento dell’operazione di build. Come intuibile dalla tabella 3.11, ad ogni mo- dulo rimane da definire la specializzazione del comportamento per l’esecuzione del- l’operazione di build.
L’operazione di build prevede il reperimento delle librerie, la generazione del bytecode java presente sui file con estensione class, e la generazione dell’archivio war pronto per il deployment o la pubblicazione. In questo senso la tabella 3.12 descrive informal- mente la sua specializzazione su ogni modulo.
Modulo Operazione di build
web Genera il bytecode e la compilazione Google Web Toolkit, costruisce l’archivio war con il bytecode e le configurazioni definite.
schemadaemon Genera il bytecode java, costruisce l’archivio war con il bytecode, configurazio- ni e alcuni script SQL definiti dal modulo db.
db Genera script SQL usando un database POSTGRES protobuf Genera sorgenti necessari al modulo schemadaemon
Tab. 3.25: descrizioni dell’implementazione dell’operazione di build su ogni modulo
Automazione delle operazioni su piattaforma software as a service
Andrea Zironda ! ! ! ! ! ! ! ! ! ! ! ! ! 49 di 71
