Università Politecnica delle Marche

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Dipartimento di Ingegneria dell'informazione CONTINUOUS INTEGRATION IN UNA WEB AGENCY Laureando: Giorgio Mandolini Relatrice: Prof.ssa Claudia Diamantini Anno Accademico 2010/2011

2

3 L entusiasmo è quando le gambe iniziano il primo passo ed il cuore è già a destinazione

4 Indice Indice 1 Introduzione Obiettivi Trattazione degli argomenti La Continuous Integration Definizione ed obiettivi Ciclo di vita del software Modello di sviluppo Waterfall Modello di sviluppo Iterativo Continuous Integration e modello di sviluppo iterativo Panoramica di un ambiente di Continuous Integration Best practices della Continuous Integration...12 i

5 Indice Utilizzo di un sistema di controllo versione Centralizzare tutto il necessario Automatizzare le build Build testate automaticamente Commit frequenti Eseguire delle build private nelle workstation locali Non inviare codice diffettoso Eseguire una build ad ogni cambiamento Non scaricare codice difettoso Riparare immediatamente le build difettose Trattare il database come il codice sorgente Garantire un feedback rapido ed efficiente Vantaggi offerti Rilasciabilità del software Rivelazione degli errori Visibilità di progetto ed aumento della comunicazione Qualità del codice Applicazione della metodologia: analisi iniziale Analisi della situazione iniziale Prima dell'introduzione del sistema di controllo versione Dopo l'introduzione del sistema di controllo versione...32 ii

6 Indice 3.2 Analisi delle mancanze Environment eterogenei Mancanza di controllo sull'integrazione Mancanza di visibilità di progetto Nessuna integrazione del database Difficoltà di ingresso nel progetto Difficoltà nel rilascio di demo Difficoltà di rilascio dell'applicazione Progettazione del cambiamento Scelta degli strumenti Sistema di controllo versione Web Server e DBMS Build scripting system Strumenti di testing Server di Continuous Integration Standardizzazione delle workstation e dei progetti Standardizzazione della struttura cartelle _data library _test web...48 iii

7 Indice _xhtml Comandi fondamentali Standardizzazione del database Introduzione del build scripting system Il target build Il target make-sql Introduzione di uno script di installazione Introduzione dei test Installazione del server di Continuous Integration Training del personale Lezioni frontali Redazione di documenti operativi Post sul corporate blog Risultati ottenuti Soluzione del problema degli environment eterogenei Soluzione del problema di integrazione del codice Soluzione del problema della visibilità di progetto Soluzione del problema di integrazione del DB Soluzione del problema di ingresso al progetto Soluzione del problema delle demo Futuri sviluppi: automatizzare il deploy iv

8 Indice 6 Bibliografia Letteratura Risorse e strumenti...72 v

9 1 Introduzione 1 Introduzione La seguente tesi si occupa di descrivere il lavoro svolto in una web agency 1, presso la quale è stata presa in considerazione l'adozione della pratica della Continuous Integration. Verranno trattate tutte le fasi che hanno contribuito alla realizzazione del lavoro: da uno studio iniziale della metodologia da introdurre, all'applicazione dei cambiamenti necessari al fine di una sua corretta implementazione. 1.1 Obiettivi L'obiettivo principale del lavoro svolto è lo studio e l'implementazione di un sistema informativo che organizzi l'azienda secondo le best practices della Continuous Integration, al fine di migliorare il processo di sviluppo software. Verranno introdotti 1 e-xtrategy s.r.l. 1

10 1 Introduzione strumenti come un sistema di controllo versione ed un server di Continuous Integration, affiancati ad un insieme di regole da rispettare per ottenere il rispetto della pratica ed il raggiungimento dei benefici offerti. 1.2 Trattazione degli argomenti Nel capitolo 2 viene illustrata la Continuous Integration, definendo quali sono i suoi obiettivi ed il problema dell'integrazione del software; viene fornita una panoramica generale di un ambiente tipico di C.I., delle best practices che lo caratterizzano e dei vantaggi promessi dall'utilizzo di questa metodologia. Il capitolo 3 si occupa dell'analisi delle mancanze ed inefficienze riscontrate in azienda: viene fornita una descrizione della metodologia di sviluppo utilizzata prima e dopo l'introduzione del sistema di controllo versione, analizzando i problemi riscontrati dal team di sviluppo in entrambi i casi. Nel capitolo 4 verranno illustrati tutti i cambiamenti necessari al fine di introdurre la Continuous Integration. In questa fase di progettazione saranno motivate le scelte tecniche, secondo due criteri: l'ambito di sviluppo dell'azienda (web application) e l'eventuale preesistenza di strumenti già adatti alla Continuous Integration. Il capitolo 5 descrive i risultati ottenuti a seguito dei cambiamenti introdotti nel capitolo 4, focalizzando l'attenzione, punto per punto, sui problemi riscontrati nel capitolo 3. In questa fase verranno espresse infine delle conclusioni sul lavoro svolto ed eventuali sviluppi futuri. 2

11 2 La Continuous Integration 2 La Continuous Integration In questo capitolo viene illustrata la Continuous Integration, definendo quali sono i suoi obiettivi ed il problema dell'integrazione del software; viene fornita una panoramica generale di un ambiente tipico di C.I., delle best practices che lo caratterizzano e dei vantaggi promessi dall'utilizzo di questa metodologia. 2.1 Definizione ed obiettivi La Continuous Integration è una pratica emersa nella comunità Extreme Programming (XP) 2, ed i principali sostenitori, Martin Fowler 3 e Kent Beck 4, iniziarono a parlarne intorno al Extreme Programming 3 Martin Fowler 4 Kent Beck Beck.htm 3

12 2 La Continuous Integration In accordo con la definizione 5 data da Martin Fowler, si può definire la Continuous Integration una pratica di sviluppo software dove i membri di un team integrano il proprio lavoro frequentemente, da una a più volte al giorno. Ogni integrazione deve essere verificata da una build automatizzata, che include dei test, per individuare errori di integrazione il più presto possibile e permettere ad un team di sviluppare software rapidamente. Il problema dell'integrazione non è nuovo nel campo dello sviluppo ed è tanto più complesso quanto più crescono le dimensioni del software e del team che ne è incaricato allo sviluppo: al crescere della complessità, infatti, cresce anche la necessità di integrare e di garantire il corretto funzionamento di tutti i componenti sviluppati dai diversi membri del team. L'obiettivo principale della Continuous Integration è appunto quello di semplificare l'integrazione del software, facendola diventare parte integrante del processo di sviluppo anziché relegarla ad una fase successiva. 5 Continuous Integration, Martin Fowler 4

13 2 La Continuous Integration 2.2 Ciclo di vita del software Possiamo mettere a confronto due modelli di processo di svulippo software ed analizzare l'impatto della fase di test/integrazione su ciascuno di essi: modello tradizionale Waterfall o A cascata modello Incrementale/Iterativo Modello di sviluppo Waterfall Figura 2.1 Modello di sviluppo Waterfall: il processo scorre dal basso verso l'alto, come una cascata. Nel modello di sviluppo waterfall ogni fase produce un output che è l'input della fase successiva. 5

14 2 La Continuous Integration L'intero software passa per ciascuna fase: 1. Requirements: viene effettuata la raccolta, l'analisi e la ristrutturazione dei requisiti. Vengono definiti i requisiti non elicitati in fase di raccolta, che può essere eseguita più volte, presso i vari stakeholders del sistema. 2. Design: viene progettato il software, in modo da rispettare i requisiti definiti nello step precedente. In questa fase viene scelta l'architettura, definite le interfacce delle classi e le relazioni tra di esse. 3. Implementation: il team procede con lo sviluppo vero e proprio del software, traducendo in linee di codice quanto progettato in fase di design. 4. Verification: tutti i componenti implementati vengono messi insieme ed il software testato. E' qui che avviene l'integrazione. 5. Maintenance: il software è entrato in produzione, in questa fase si procede al suo mantenimento, come eventuali bug fix o aggiornamenti. 6

15 2 La Continuous Integration Modello di sviluppo Iterativo Figura 2.2 Modello di sviluppo Iterativo, il processo evolve all'interno di ciascuna iterazione, a seguito della quale avviene un rilascio di software già funzionante. Nel modello di sviluppo iterativo, si riconoscono fasi simili al modello waterfall, ma in questo caso non si fa passare l'intero software per ogni fase, bensì una sola porzione alla volta. Anche in questo modello ogni fase produce un output che è l'input della fase successiva, con la differenza che al termine di ciascuna iterazione il software sarà aumentato di funzionalità. Ad ogni iterazione si ha una fase di rilascio (deploy) di software già integrato e funzionante. Esclusa la prima iterazione, tutte le successive avranno come input il software già presente ed un insieme di nuovi requisiti da implementare Continuous Integration e modello di sviluppo iterativo Sulla base delle caratteristiche dei modelli di sviluppo precedentemente illustrati, si può 7

16 2 La Continuous Integration affermare che la Continuous Integration ben si coniuga con una metodologia incrementale/iterativa. Su questo tipo di modelli di sviluppo infatti, l'integrazione del software è un evento che avviene frequentemente a differenza del modello a cascata, in cui viene fatta solamente al termine dell'implementazione, per poi essere testata nella sua interezza in fase di collaudo e verifica. Il vantaggio di un modello iterativo sta quindi nel costo di gestione dei bug, sia di sviluppo che di integrazione. E' riconosciuto infatti che tale costo è tanto più elevato quanto più tardi viene scoperto. La Continuous Integration ha inoltre come ulteriore scopo quello di individuare eventuali errori ancora prima: questo significa che per rilevare malfunzionamenti non è necessario attendere il termine dell'iterazione o dell'intero processo di sviluppo. Di seguito due grafici qualitativi, per il costo di risoluzione di un bug: Figura 2.3 Andamento del costo di un bug in funzione del momento di rivelazione, per il modello di sviluppo Waterfall. 8

17 2 La Continuous Integration Figura 2.4 Andamento del costo di un bug in funzione del momento di rivelazione, per il modello di sviluppo Iterativo. Com'è possibile notare, nel caso di un approccio iterativo le tre macro fasi Requisiti, Sviluppo e Test vengono ripetute ad ogni iterazione, portando ai seguenti vantaggi: Requisiti aggiornati ad ogni iterazione: il cliente può decidere di cambiare requisiti in corso d'opera, senza l'implicazione una completa riscrittura del software. Sviluppo incrementale: il software viene scritto sulla base dei requisiti dell'iterazione corrente, che sono quindi temporalmente vicini ed a priorità più alta. Il rischio di scrivere componenti inutilizzati o sovraingegnerizzati è relegato alla singola iterazione e non a tutto lo sviluppo. Test frequenti: ciascuna nuova funzionalità aggiunta viene testata al momento della sua introduzione, rispettando quindi il criterio per cui un bug è tanto meno costoso quanto prima viene scoperto. 9

18 2 La Continuous Integration 2.3 Panoramica di un ambiente di Continuous Integration Gli attori fondamentali in un ambiente di Continuous Integration sono: Lo sviluppatore. Un sistema di controllo versione. Un sistema di automazione delle build. Un sistema di testing delle build. Un server di Continuous Integration. Figura 2.5 Panoramica di un ambiente di Continuous Integration, con i principali attori che contribuiscono al funzionamento del sistema. 10

19 2 La Continuous Integration Il funzionamento generale di un sistema di Continuous Integration è il seguente: 1. Lo sviluppatore esegue i cambiamenti necessari al codice: implementa la feature richiesta, fino a che non la ritiene completata. Insieme ad essa, scrive i test automatici che la riguardano. 2. Esegue una build privata sulla propria workstation: attraverso il processo di build vengono eseguiti tutti i task necessari alla corretta preparazione del software, prima del suo rilascio. In questa fase, oltre alla compilazione, intervengono i test automatici. 3. Invio del codice al repository: una volta soddisfatti tutti i test, lo sviluppatore invia i propri cambiamenti al sistema di controllo versione. 4. Build di integrazione: il Continuous Integration server periodicamente reperisce l'ultima versione del software dal repository ed effettua una nuova build automatica, comprensiva di test, che sarà il prodotto dei cambiamenti inviati da tutti gli sviluppatori del team. 5. Feedback: se il processo di build da parte del Continuous Integration server va a buon fine, erro genera un feedback positivo (es: tramite e- mail o un monitor ben visibile dal team) ed il software è pronto al rilascio. Viceversa il feedback sarà negativo e la soluzione del problema individuato diventa prioritaria rispetto lo sviluppo di nuove funzionalità 11

20 2 La Continuous Integration 2.4 Best practices della Continuous Integration Di seguito verranno illustrate le pratiche fondamentali per implementare correttamente un sistema di Continuous Integration e come esse influenzano il processo di sviluppo. E' importante sottolineare che la Continuous Integration è in primis una pratica e come tale agisce radicalmente sul processo di sviluppo Utilizzo di un sistema di controllo versione L utilizzo di un sistema di controllo versione è un requisito fondamentale per costruire un ambiente di Continuous Integration. Lo scopo di questo strumento è la gestione dei cambiamenti del codice sorgente e di tutto il necessario per la corretta compilazione del software. L'obiettivo principale è quello di avere un repository centralizzato, che permetta di gestire e monitorare i cambiamenti che avvengono sulla base di codice. Non vi è preferenza sulla scelta dello specifico strumento: l'unico requisito è quello di avere un unico punto di accesso al codice, detto mainline o trunk, mentre le differenze che intercorrono tra i vari sistemi di controllo versione non sono influenti. Con questo strumento si introduce la possibilità di rollback dei cambiamenti: viene tenuta traccia della storia di ciascun file, fornendo la possibilità di tornare indietro in caso di necessità. 12

21 2 La Continuous Integration Centralizzare tutto il necessario La Continuous Integration impone che il software e tutto il necessario al suo funzionamento, compresi framework, librerie, dipendenze esterne, test e build script, sia messo sotto controllo versione all interno del repository: esso dovrà fungere da single source point del codice e l'applicazione dovrà essere in grado di funzionare solamente con ciò che vi è contenuto, senza interventi esterni o aggiunte manuali. Questo è necessario per garantire uniformità negli environment di sviluppo: le librerie che i client degli sviluppatori usano per ciascun progetto provengono dal repository e non da fonti esterne, permettendo di: 1. Risparmiare tempo in termini di ricerca ed installazione delle librerie e delle dipendenze da parte dello sviluppatore. 2. Eliminare il rischio di installare versioni di librerie non aggiornate, mal funzionanti o non compatibili. Oltre a ciò, viene aumentata la velocità di ingresso al progetto da parte di eventuali nuovi membri del team: una volta ottenuto l'accesso al repository, non devono essere compiute ulteriori azioni esterne ad esso. 13

22 2 La Continuous Integration Automatizzare le build Il processo di build non include la sola compilazione del codice, ma anche un determinato numero di azioni, tra le quali il setup e popolazione del database con valori noti (fixtures), che permettono al software di essere correttamente costruito e reso funzionante. E' necessario rendere questo insieme di passaggi automatico attraverso un singolo script di build perché in questo modo: 1. Si limita l intervento umano: la probabilità di errori ed omissioni viene ridotta, in quanto lo sviluppatore utilizza un singolo comando. 2. Si migliora la riproducibilità: tutti gli sviluppatori eseguono gli stessi passaggi in maniera identica, evitando il cosiddetto but it works on my machine, dove il software risulta funzionante su alcuni ambienti e non su altri. 14

23 2 La Continuous Integration Figura 2.1 Tipici step di un generico script di build. Lo script stesso deve essere considerato parte del software e come tale soggetto ad evoluzione. 15

24 2 La Continuous Integration Build testate automaticamente Una delle peculiarità della Continuous Integration è l'utilizzo di test automatici che devono essere inoltre inglobati nei build script. A build completata lo sviluppatore conoscerà il risultato del proprio lavoro e grazie all'esito dei test sarà in grado di averne confidenza sulla bontà. Non è contemplata la verifica ed il collaudo manuale dell'applicazione, esplorando di volta in volta ciascuna delle funzionalità richieste, perché è necessario evitare omissioni, soprattutto nel modello di sviluppo che si sta introducendo. La fase di test viene infatti ripetuta ad ogni build, non è umanamente possibile testare il software manualmente numerose volte al giorno, per ogni cambiamento introdotto. Testare le applicazioni manualmente porta alla cattiva pratica di non verificare quelle parti di codice per le quali si da per scontato il corretto funzionamento, in quanto si assume che le modifiche introdotto non influenzino certi punti del software. Questo, sebbene logico, è comunque non accettabile in un ambiente in cui la garanzia di rilevare errori il prima possibile è considerata una priorità. I test automatici servono ad evitare questa situazione: minori saranno le assunzioni e maggiori saranno le garanzie di un software effettivamente funzionante. I test automatici sono sempre ripetibili nella stessa identica maniera, in qualsiasi istante: ad ogni build verificano tutte le funzionalità per cui sono stati scritti, più velocemente ed in maniera più affidabile di un umano. Non è pensabile che una persona riesca ad eseguire un gran numero di volte la stessa batteria di test senza introdurre di volta in 16

25 2 La Continuous Integration volta piccole differenze, perché, proprio per natura, è influenzabile da molteplici fattori non deterministici come l'umore, la concentrazione e la stanchezza. I test automatici sono invece deterministici e si fanno carico di un compito ripetitivo e noioso, ma al tempo stesso critico Commit frequenti Uno dei principi fondamentali per ottenere vantaggi dalla Continuous Integration è quello di integrare poco, presto e spesso. Più si attende prima di inviare codice al repository, più il processo di integrazione richiederà del tempo, per via della maggior quantità di dati da integrare, oltre al fatto che gli altri membri del team, nel frattempo, non avranno tenuto conto degli ultimi cambiamenti. Si possono utilizzare le tecniche a seguito descritte per aumentare la frequenza di commit al repository: 1. Eseguire piccoli cambiamenti: non cambiare più componenti software insieme ma scegliere piccoli task per i quali scrivere dei test automatici ed implementare il codice necessario al loro soddisfacimento. Una volta eseguiti e passati tutti i test, inviare il codice al repository. 2. Suddividere il lavoro in task atomici: in altre parole, favorire la 17

26 2 La Continuous Integration scrittura di unit of work a bassa interdipendenza, quindi semplici da integrare, con codice più snello e meno prono a complessità. In altri termini rispettare il KISS principle (Keep It Simple, Smart) [4], secondo il quale la migliore soluzione ad un problema, a parità di risultati, è quella a complessità minore. La principale motivazione a supporto di questa regola risiede nella probabilità di introduzione di un bug a seguito di una commit. Possiamo infatti affermare che la probabilità di introduzione di un errore di integrazione è funzione crescente del numero delle linee di codice che hanno influenzato la modifica. Per cui: P bug (N 1 ) P bug ( N 1 ) se N 1 N 2, con N 1,N 2 numero di lineedi codice affette dalla modifica. Ne consegue che piccoli cambiamenti integrati frequentemente, rappresentano un criterio di sviluppo più sostenibile, in cui si punta più al non introdurre bug, piuttosto che correggerli in un secondo momento Eseguire delle build private nelle workstation locali Prima di iniziare con lo sviluppo di nuove funzionalità, ciascun membro è tenuto a scaricare dal repository l ultima versione del software. A questo punto potrà lavorare 18

27 2 La Continuous Integration nella propria workstation, effettuando i cambiamenti necessari al completamento del proprio lavoro. Una volta terminato dovrà essere effettuata una build del software sulla workstation ed osservarne i risultati. Se tutto procede correttamente, prima di inviare le proprie modifiche al repository, scaricherà di nuovo da questo gli eventuali cambiamenti effettuati nel frattempo dagli altri sviluppatori e rilancerà la build, integrando di fatto il software. Se tutto va a buon fine, è stato fatto un primo passo verso l integrazione: i cambiamenti sono stati integrati ed è possibile aggiornare la code-base eseguendo la commit verso il repository. Figura 2.2 Step fondamentali eseguiti dallo sviluppatore per eseguire una build di integrazione locale. 19

28 2 La Continuous Integration Non inviare codice diffettoso In caso di fallimento dei test durante la build privata, lo sviluppatore dovrà correggere i malfunzionamenti e rieseguire la build fino alla completa risoluzione dei problemi riscontrati. Non potrà, in nessun caso, inviare modifiche al repository se i test non certificano che esso è correttamente funzionante. Con questa regola si minimizza la probabilità di avere software non funzionante nel repository: la copia malfunzionante resterà confinata nella macchina dello sviluppatore che si occuperà di ripararla Eseguire una build ad ogni cambiamento Ogni volta che il repository viene aggiornato con nuovi cambiamenti, il codice necessita di essere ritestato per avere la garanzia che non siano stati introdotti dei difetti. Successivamente alle build private, quindi, si esegue la vera e propria build di integrazione, su di una macchina dedicata che deve riprodurre il più fedelmente possibile il vero ambiente di produzione. Al pari dei client degli sviluppatori, è importante che questa macchina sia priva di dipendenze e librerie spurie che non provengano direttamente dal repository: in questo modo si accerta che il lavoro dello sviluppatore sia ancora riproducibile e non dipenda da una particolare configurazione a livello locale. L integration build può essere manuale o effettuata automaticamente tramite un Continuous Integration server. 20

29 2 La Continuous Integration Sebbene l'utilizzo di un integration server non sia obbligatorio, è comunque raccomandato usarne uno: esso infatti rileverà i cambiamenti sul repository ed eseguirà le build automaticamente, fornendo inoltre una dashboard con report sui test, code coverage, strumenti di analisi aggiuntivi ed eventuale documentazione auto-generata Non scaricare codice difettoso Nell'ipotesi in cui la build di integrazione fallisca, nonostante siano state correttamente effettuate le build private, sorge il problema della broken build : è entrato un bug nella code base e tutti i membri del team che andranno a scaricarlo otterrebbero del software non funzionante. Quando questo avviene la pratica impone di non scaricare affatto il codice difettoso e, se possibile, continuare lo sviluppo tramite la propria copia locale, sebbene non aggiornata, per poi integrarla in un secondo momento. Piuttosto che sviluppare eventuali workaround per far funzionare il software difettoso nella propria workstation è preferibile aiutare gli altri membri del team a far tornare la build nel suo corretto stato di funzionamento Riparare immediatamente le build difettose E' compito dello sviluppatore che ha eseguito l'ultima commit risolvere il problema di una build difettosa. E' importante che questo venga fatto immediatamente, perché è un 21

30 2 La Continuous Integration problema che coinvolge tutto il team, che a questo punto non può avere fiducia su quanto contenuto nel repository. Nell'ipotesi in cui la build di integrazione fallisca, infatti, deve essere considerata come prioritaria la soluzione dei problemi emersi piuttosto che lo sviluppo di nuove funzionalità. Come detto precedentemente, è vietato scaricare codice non funzionante: di fatto la regola descritta in precedenza attiverebbe subito tutto il team alla soluzione del problema, in quanto non potrebbe aggiornare il codice delle macchine locali per continuarne lo sviluppo Trattare il database come il codice sorgente Il database dell'applicazione fa parte del software e come tale deve essere posto sotto controllo di versione. Figura 2.2 La sequenza dell'integrazione automatica del db. Il build script si occupa di far eseguire lo script di definizione al DBMS, per poi procedere con l'inserimento dei dati. 22

31 2 La Continuous Integration E' compito del build script gestire il DB: così facendo si può tener traccia anche dei cambiamenti effettuati sulla struttura e sui dati nella stessa maniera con cui viene effettuato con il codice sorgente. Per fare ciò è necessario gestire su file le procedure di Data Definition Language (DDL) e Data Manipulation Language (DML) ed aggiungerle al repository, che in questo modo continua ad essere l'unica fonte a cui attingere per lo sviluppo del sofware. Figura 2.3 Esempio di integrazione del database, dove entrambi gli sviluppatori possono eseguire modifiche ai dati ed allo schema. 23

32 2 La Continuous Integration Garantire un feedback rapido ed efficiente E' importante che il processo di build rapido: come regola empirica ci si impone un limite di attesa massimo di 10 minuti per il risultato della build (regola del 10 minute build ). Questo è necessario al fine di non indurre gli sviluppatori ad accumulare troppe linee di codice prima di rieseguire la build, andando contro uno dei principi cardine della Contiuous Integration. Per evitare questo anti pattern sono previste più soluzioni: 1. Eseguire delle staged-build: le build private vanno accompagnate solamente da test unitari e le build di integrazione divise in due: test unitari prima (per individuare subito i problemi più grossolani) per le build lanciate ad ogni commit e test più approfonditi (unitari e funzionali, analisi del codice, delle dipendenze, del code-style, ecc) per build lanciate in un successivo momento, per esempio schedulate in notturna o in seguito al successo delle precedenti build eseguite immediatamente dopo la commit. 2. Aumentare le risorse hardware: garantire una sufficiente potenza di calcolo, sia per le workstation sia per la macchina dedicata all'integrazione finale del codice. Avere una build veloce serve all'ottenimento di un feedback rapido che deve essere coadiuvato da meccanismi che lo rendano facilmente individuabile e interpretabile, 24

33 2 La Continuous Integration alcune soluzioni proposte dalla pratica sono: Un monitor sempre ben visibile al team, sul quale è possibile vedere continuamente lo stato delle build dei vari progetti. Meccanismi di allarme visivi e/o sonori per segnalare malfunzionamenti (lampada verde/rossa, allarme sonoro). Una combinazione dei precedenti. A prescindere dal criterio di feedback scelto, è importante che esso sia incentrato sulle informazioni utili ed essenziali, tutto il superfluo aumenta il rischio di far passare inosservati messaggi realmente importanti. A tal proposito è utile considerare i seguenti fattori, tra essi correlati: L'informazione: ciò che il sistema deve comunicare. Il destinatario: chi deve ricevere il messaggio. Gli sviluppatori sono interessati allo stato di funzionamento della build, mentre un Project Manager è più interessato ad un andamento globale del progetto (es: metriche sulla qualità del software). 25

34 2 La Continuous Integration Il modo: il meccanismo di comunicazione scelto, come ad esempio una barra verde/rossa per lo stato di una build o un grafico (anziché dei dati in forma tabellare) per il suo andamento nel tempo. I tempi: le informazioni sono deperibili nel tempo. E' fondamentale che esse giungano a destinazione e vengano correttamente interpretate entro un determinato tempo massimo, altrimenti diventano inutili. 2.5 Vantaggi offerti Di seguito verranno illustrati i principali vantaggi offerti dal rispetto delle best pratices imposte dalla Continuous Integration Rilasciabilità del software Grazie ad un approccio incrementale, lo sviluppo non è più eseguito orizzontalmente. In altre parole la progettazione del software non viene più fatta a livelli (es: gui, business logic, database) che poi vengono integrati, ma diventa verticale sulla singola funzionalità in fase di realizzazione. Nel primo caso il software è rilasciabile solamente al termine dell'integrazione finale di tutti i livelli, mentre nel secondo ogni funzionalità porta già con se la porzione dei livelli interessati. Grazie alle integrazioni continue tra tutte le funzionalità, nel repository è sempre presente una versione funzionante del software, anche se incompleto, mentre nel 26

35 2 La Continuous Integration caso precedente ciò non è possibile, in quanto un livello interamente sviluppato non ha alcuna utilità se il livello da cui dipende non è stato ancora completato. Intero software GUI Business Logic Database Figura 2.4 Sviluppo non incrementale: il software viene sviluppato orizzontalmente, mentre l'integrazione è verticale. Funzionalità 1 Funzionalità 2 Funzionalità 3 Funzionalità n GUI 1 GUI 2 GUI 3 GUI n Business Logic 1 Business Logic 2 Business Logic 3 Business Logic n Database 1 Database 2 Database 3 Database n Figura 2.5 Sviluppo incrementale: il software viene sviluppato verticalmente, mentre l'integrazione è orizzontale Rivelazione degli errori Il rispetto della pratica delle build private e l'utilizzo dei test automatici fornisce un sistema efficiente di prevenzione e rivelazione degli errori, che vengono individuati velocemente anche grazie ad un feedback opportuno. L'eseguire una build ad ogni cambiamento è un supporto alla rivelazione istantanea dei bug, che restano confinati a porzioni di codice limitate e recenti. Grazie a ciò la risoluzione di eventuali problemi viene semplificata. 27

36 2 La Continuous Integration Visibilità di progetto ed aumento della comunicazione L'utilizzo di un repository in cui centralizzare tutti gli elementi che compongono il software, coadiuvato da un meccanismo di feedback opportuno aumenta la visibilità del progetto da parte del team, che in questo modo è in grado di monitorarne costantemente l'andamento. In questo modo si ha un aumento di comunicazione sia interna che verso l'esterno: è possibile infatti tenere aggiornato il cliente sull'andamento generale del progetto e studiare con esso eventuali misure correttive o cambi di direzione, già prima della scadenza finale Qualità del codice L'utilizzo di un Continuous Integration server permette di eseguire automaticamente e continuamente una serie di task ripetitivi e dispendiosi, come ad esempio: L'analisi della complessità del codice L'analisi dell'interdipendenza tra classi Il rispetto del code style L'analisi della duplicazione del codice L'analisi della copertura dai test 28

37 2 La Continuous Integration Tutte queste operazioni tendono ad aumentare la qualità del prodotto, è infatti possibile scegliere di far fallire una build qualora una o più di queste metriche scendano al di sotto di una soglia prestabilita ed imporre quindi il rispetto degli standard prefissati. 29

38 3 Applicazione della metodologia: analisi iniziale 3 Applicazione della metodologia: analisi iniziale Questo capitolo si occupa dell'analisi delle mancanze ed inefficienze riscontrate in azienda: viene fornita una descrizione della metodologia di sviluppo utilizzata prima e dopo l'introduzione del sistema di controllo versione, analizzando i problemi riscontrati dal team di sviluppo in entrambi i casi. 3.1 Analisi della situazione iniziale Al momento dell'analisi, l'azienda era già in una situazione di transizione verso l'utilizzo di un sistema di controllo versione, nello specifico SVN 6, per la gestione del codice. Lo strumento era già stato introdotto e correttamente configurato, ma non erano ancora state introdotte le conoscenze e la corretta disciplina per un suo utilizzo efficiente. 6 Apache Subversion 30

39 3 Applicazione della metodologia: analisi iniziale Prima dell'introduzione del sistema di controllo versione Lo sviluppo delle applicazioni web veniva effettuato tramite un server centrale contenente i sorgenti, il webserver ed il DBMS necessario alla loro esecuzione: le macchine client degli sviluppatori interagivano direttamente con esso. Gli sviluppatori, connessi ai sorgenti tramite mount point su rete locale effettuavano i cambiamenti necessari al completamento del proprio lavoro. L'approccio era quindi centralizzato, e prevedeva i seguenti step: 1. Accesso alle risorse del server di sviluppo tramite rete LAN, 2. modifica diretta dei file sorgente dell'applicazione in sviluppo, 3. accesso all'applicazione tramite browser web per la verifica dei risultati. Figura 3.1 Flusso di lavoro dell'azienda prima dell'introduzione del sistema di controllo versione. 31

40 3 Applicazione della metodologia: analisi iniziale Con questo approccio l'azienda ha lamentato vari inconvenienti, tra i quali: Mancanza di uno storico delle modifiche ai files e di chi le avesse effettuate. Impossibilità di poter effettuare dei rollback immediati, che non passassero necessariamente per il sistema di backup del server. Possibilità di collisione tra sviluppatori che potevano avere la necessità di modificare lo stesso file contemporaneamente. Blocco del lavoro dell'intero team di sviluppo qualora uno sviluppatore provocasse il malfunzionamento dell'applicazione Dopo l'introduzione del sistema di controllo versione Per i motivi appena citati si è proceduto all'installazione di Subversion sul server di sviluppo e gradualmente migrare tutti i lavori all'interno del nuovo repository. Il processo di sviluppo è quindi passato da centralizzato a distribuito: ogni client si connette al repository contenente i sorgenti, li scarica in locale e lavora con essi, per poi rimandarli al server una volta terminate le modifiche. La modalità appena introdotta è sensibilmente differente da quella vista in precedenza: ciascun client ora dovrà essere dotato di un proprio webserver per eseguire le applicazioni e di un proprio DBMS qualora queste ne richiedano uno. 32

41 3 Applicazione della metodologia: analisi iniziale Figura 3.2 Flusso di lavoro dopo l'introduzione del sistema di controllo versione. Il nuovo processo di sviluppo è caratterizzato quindi dai seguenti step: 1. Installazione del progetto sulla workstation: 1. Modifica manuale del file degli host locale per navigare l'applicazione web. 2. Creazione di un database dedicato all'applicazione. 2. Sviluppo del progetto: 1. Checkout del codice, dal repository verso la macchina client. 2. Sincronizzazione manuale del database, tramite l'importazione di 33

42 3 Applicazione della metodologia: analisi iniziale file SQL provenienti dalla versione legacy dell'applicazione o salvati nel repository. 3. Modifica dei sorgenti in locale. 4. Accesso all'istanza locale dell'applicazione tramite browser web per la verifica dei risultati. 5. Invio dei nuovi sorgenti al repository. 3.2 Analisi delle mancanze L'introduzione di SVN nel processo di sviluppo dell'azienda ha incontrato inizialmente una certa inerzia a causa della prospettiva di sviluppo letteralmente invertita. L'abitudine degli sviluppatori di lavorare direttamente con l'applicazione nel server di sviluppo si è scontrata con l'avere tante copie locali per ciascuna workstation. Di seguito, saranno descritti i probleami individuati Environment eterogenei Ogni client presenta delle differenze, più o meno marcate, a seconda delle preferenze dello sviluppatore che ne fa uso o della configurazione hardware/software. Tali differenze sono risultate essere: il sistema operativo utilizzato (Linux / Mac OS) la configurazione del webserver (es: i path fisici dove viene salvata 34

43 3 Applicazione della metodologia: analisi iniziale l'applicazione). la configurazione del DBMS (es: eterogeneità delle credenziali di accesso al database utilizzato da una determinata applicazione). Le librerie esterne ed i framework necessari al funzionamento del progetto che possono presentare discrepanze sul numero di versione o risiedere in path differenti. Di conseguenza quando l'applicazione viene scaricata sulla macchina locale potrebbe non funzionare correttamente e necessitare di una riconfigurazione. Dato per assunto che tutte le applicazioni siano ben scritte e quindi parametrizzabili tramite un singolo file di configurazione (es: config.xml) resta comunque il problema di dover gestire collisioni di configurazione che sono tante quante sono i client di sviluppo, più la configurazione finale per l'ambiente di produzione, dove la release dovrà lavorare per il cliente. Lo scenario è quindi il seguente: 1. Lo sviluppatore scarica l'applicazione 2. Effettua la riconfigurazione 3. Lavora sull'applicazione 4. Invia le modifiche al repository 35

44 3 Applicazione della metodologia: analisi iniziale Tale modalità evidenzia subito un'inefficienza: si nota infatti che ad ogni commit sul repository la configurazione viene di volta in volta sovrascritta, ed a causa di ciò si va incontro a due problemi: 1. La necessità di riconfigurare l'applicazione ad ogni aggiornamento ricevuto dal repository. 2. Nel repository non è mai presente una versione dell'applicazione che sia già rilasciabile e correttamente configurata per l'ambiente di produzione. Il primo problema è una criticità che abbassa l'efficienza e la produttività del team: oltre al tempo necessario all'effettiva riconfigurazione si introduce un fattore di rischio dovuto alla possibilità di commettere errori durante questa fase. In altre parole si sta sprecando tempo in un task che non porta alcun valore: la riconfigurazione non aggiunge funzionalità all'applicativo, tantomeno ne migliora alcune preesistenti, pertanto ha valore pari a zero. Il secondo problema è un fattore di rischio che potrebbe portare a problemi in fase di rilascio dell'applicazione, che porta con se altri due svantaggi: 1. Non si ha la certezza che l'applicativo sia effettivamente funzionante una volta rilasciato nell'ambiente di produzione. 36

45 3 Applicazione della metodologia: analisi iniziale 2. La pubblicazione di nuove features è ogni volta rallentata dal processo manuale di configurazione Mancanza di controllo sull'integrazione Con la modalità centralizzata ciascuno sviluppatore era costretto a lavorare su porzioni indipendenti dell'applicativo, in quanto non vi era nessun meccanismo di sviluppo concorrente. Con l'introduzione di Subversion questo limite è stato rimosso: grazie al controllo di versione è infatti possibile poter effettuare cambiamenti concorrenti anche sulle stesse aree di codice e poter gestire le collisioni tramite i meccanismi di risoluzione offerti dallo strumento. Resta però il problema dell'integrazione, cioè garantire che la risoluzione dei conflitti sia effettivamente corretta e non causi malfunzionamenti Mancanza di visibilità di progetto Diretta conseguenza del problema visto precedentemente è la mancanza di visibilità sul progetto: il fatto che il software funzioni sulla workstation locale dello sviluppatore non garantisce il corretto funzionamento della build presente nel repository. Qualora due o più sviluppatori lavorino sulla stessa area di codice, al momento della commit Subversion si occupa di segnalare l'avvenuta collisione e permetterne la 37

46 3 Applicazione della metodologia: analisi iniziale risoluzione del conflitto: sebbene questo sia un primo livello di protezione, non si ha comunque la garanzia che l'integrazione sia avvenuta correttamente. Ciascuno sviluppatore è infatti responsabile delle modifiche che introduce, ma senza un meccanismo che permetta automaticamente di evidenziare effetti collaterali in altri punti del codice si potrebbero introdurre inavvertitamente dei malfunzionamenti che in prima analisi potrebbero non essere visibili Nessuna integrazione del database Con l'abbandono del server centrale si è passati da un un'unica istanza dell'applicazione in sviluppo ad n istanze, una per ogni client coinvolto nel processo di sviluppo. Replicare il codice in tutte le workstation locali non è visto come un particolare problema, ma per quanto riguarda la gestione del database sono emerse alcune problematiche: Non esiste più un DBMS centralizzato, al quale tutti fanno riferimento Non c'è un meccanismo di integrazione tra i cambiamenti ai dati e alla struttura, effettuati nelle copie locali. Tali problematiche, non emergevano invece con il vecchio approccio centralizzato: la macchina di sviluppo era unica, come pure il DBMS e l'istanza dell'applicativo. 38

47 3 Applicazione della metodologia: analisi iniziale Difficoltà di ingresso nel progetto Una delle difficoltà avvertite dall'azienda è stata la difficoltà di ingresso nel progetto da parte di nuovi membri del team. E' necessario che tutto passi per un client locale, che deve essere configurato affinché sia in grado di ospitare correttamente il progetto, anche per piccolissime modifiche. Il tempo necessario al setup e bootstrap manuali dell'applicazione in locale, complice anche l'eterogeneità degli environment precedentemente descritta, spesso supera il tempo necessario all'implementazione delle modifiche richieste Difficoltà nel rilascio di demo Creare una demo del software significa consegnare al cliente una prima versione funzionante di ciò che è attualmente in sviluppo dentro il repository. Questo processo è risultato essere lento e macchinoso, in quanto eseguito manualmente. Emerge quindi la necessità di automatizzare questa fase e studiare un meccanismo che automaticamente si occupi di scaricare dal repository l'ultima versione del software e pubblicarla in un server di demo Difficoltà di rilascio dell'applicazione Un problema simile a quello del rilascio di demo, ma molto più delicato e critico è 39

48 3 Applicazione della metodologia: analisi iniziale quello del rilascio ufficiale. La differenza sta nel fatto che in questo caso la destinazione non è più il server di demo, in cui eventuali malfunzionamenti o imprecisioni possono essere ancora tollerati, ma nel server ufficiale di produzione, dove l'applicazione entrerà definitivamente in produzione per il cliente. Diventa quindi necessario l'utilizzo di strumenti come FTP o SFTP per l'invio dei files e prestare la massima attenzione nel non commettere errori in un ambiente in cui questi non sono assolutamente tollerabili. In questa fase si sta consegnando il software al cliente, è quindi necessario ripulirlo di tutti gli assets aggiuntivi come i files di gestione di Subversion e tutto ciò che non è necessario: mantenere questi files potrebbe rappresentare una vulnerabilità del sistema, oltre che uno spreco di spazio. 40

49 4 Progettazione del cambiamento 4 Progettazione del cambiamento In questo capitolo verranno illustrati tutti i cambiamenti necessari al fine di introdurre la Continuous Integration. In questa fase di progettazione saranno motivate le scelte tecniche, secondo due criteri: l'ambito di sviluppo dell'azienda (web application) e l'eventuale preesistenza di strumenti già adatti alla Continuous Integration. 4.1 Scelta degli strumenti La scelta è stata fatta preferendo tutti quegli strumenti inerenti alle tecnologie web, reputati quindi più adatti per la tipologia di applicazioni sviluppate dall'azienda. 41

50 4 Progettazione del cambiamento Sistema di controllo versione E' stato scelto il sistema di controllo di versione Subversion 7 (o SVN) in quanto già utilizzato dall'azienda presa in esame. Per quanto riguarda il server contenente il repository non sono state effettuate modifiche, perché già correttamente configurato per essere usufruito sia dalla rete locale interna che da remoto, tramite una connessione sicura SSH. Sono state dotate di un client SVN tutte le workstation che non ne erano munite, in modo da renderlo disponibile per tutta l'azienda Web Server e DBMS L'azienda sviluppa principalmente applicazioni web in PHP, per le quali il tipico web server è Apache 8. Il DBMS scelto, sempre in relazione al tipo di software sviluppato, è MySQL 9. La tipica installazione scelta è quindi di tipo LAMP (Linux, Apache, MySQL, PHP) per i client di tipo Linux, oppure MAMP (Mac, Apache, MySQL, PHP) per i client basati su sistema operativo Mac OS. Per entrambe è stato scelto il software Zend Server 10. Non sono state infine rilevate macchine dedicate allo sviluppo, dotate di sistema operativo Windows. 7 Apache Subversion 8 Apache HTTP Server Project 9 Oracle MySQL 10 Zend Server 42

51 4 Progettazione del cambiamento Build scripting system Come strumento per lo sviluppo ed esecuzione degli script di build è stato scelto Phing 11, in quanto specifico per il linguaggio PHP, con il quale è possibile scrivere eventuali plugin o estensioni. Esso fa uso di un file di build (di tipo XML), attraverso il quale è possibile definire una serie di attività (dette target ) composte da operazioni (detti task ) da eseguire in automatico. I task che si possono eseguire attraverso Phing coprono ampiamente le richieste della Continuous Integration, infatti con essi si possono effettuare, tra le altre, le seguenti operazioni: operazioni su file system operazioni su database esecuzione di test automatici operazioni FTP ed SFTP interazione con la shell fornita dal sistema operativo 11 Phing 43

52 4 Progettazione del cambiamento Strumenti di testing Con i test unitari si verifica il funzionamento dell'applicazione ad un livello atomico: le classi dell'applicazione vengono testate singolarmente e si testano uno a uno i metodi che le compongono. Con i test funzionali si testa l'applicazione ad un livello più alto: attraverso una procedura automatizzata si simula l'interazione uomo-macchina e si verifica se i risultati ottenuti combaciano con quelli attesi. Per lo sviluppo dei test automatici sono stati scelti i seguenti software: 1. PHPUnit 12 per la scrittura di test unitari. 2. Selenium IDE e Selenium RC 13 per i test funzionali. La scelta di PHPUnit è motivata dal fatto che l'azienda sviluppa le proprie applicazioni utilizzando il linguaggio PHP. PHPUnit fa inoltre parte della famiglia dei framework di testing xunit (disponibile per un elevato numero di linguaggi tra cui Java con JUnit e.net con NUnit) con la quale condivide la sintassi e la modalità di funzionamento. 12 PHPUnit 13 Selenium, Web Browser Automation 44

53 4 Progettazione del cambiamento Figura 4.1 Screenshot del software Selenium IDE, con il quale effettuare la registrazione delle sessioni di navigazione. Selenium IDE e Selenium RC sono stati invece scelti in quanto le applicazioni sviluppate dall'azienda sono nello specifico dei siti internet: Selenium IDE consente di registrare delle sessioni di navigazione, mentre Selenium RC in accoppiata a PHPUnit è in grado di rieseguirle senza intervento umano, lanciando una istanza di browser reale. 45

54 4 Progettazione del cambiamento Server di Continuous Integration Durante la fase di analisi in azienda, è stato scelto Hudson 14 come server di Continuous Integration, in quanto di agevole installazione e configurazione, ma soprattutto integrabile con gli strumenti introdotti in precedenza. Hudson offre infatti supporto a: 1. Numerosi sistemi di controllo di versione, tra cui SVN 2. Vari linguaggi di build scripting, tra cui phing Supporta infine in maniera soddisfacente l'integrazione con i risultati forniti dai test eseguiti con il framework PHPUnit, permettendo la visualizzazione nella dashboard sia dei risultati che di ulteriori dettagli come la code coverage. 4.2 Standardizzazione delle workstation e dei progetti A seguito dell'installazione degli strumenti elencati precedentemente, tutte le workstation sono state configurate in modo da avere a disposizione tutti i comandi necessari ad eseguire il processo di build del software e tutte le operazioni ad esso connesse che vanno automatizzate. 14 Hudson Continuous Integration 46

55 4 Progettazione del cambiamento Oltre alla standardizzazione degli environment delle worstation si è proceduto con la definizione di una struttura comune a tutti i progetti Standardizzazione della struttura cartelle Per ciascun progetto è stata definita una struttura cartelle consistente, che va sempre rispettata con rigore, in modo da permettere a ciascun membro del team di reperire il necessario nel più breve tempo possibile e senza ambiguità. Di seguito la struttura scelta, comprensiva dei files fondamentali:. _data database.create.db.sql database.dati.sql database.struttura.sql install.sh LINUX_dominio.conf MAC_httpd.conf library _tests functional unit web index.php _xhtml build.xml Figura 4.2 Struttura cartelle scelta, da rispettare per ciascun progetto presente nel repository dell'azienda _data In questa cartella sono presenti tutti i dati necessari all'installazione del progetto e la 47

56 4 Progettazione del cambiamento popolazione dei dati a partire da valori noti. Qui possiamo trovare i senguenti files: database.create.db.sql per la creazione del database. database.dati.sql contiene i dati iniziali del database, detti fixtures. database.struttura.sql contiene la struttura del database. install.sh è uno script bash, per l'installazione del progetto nella worskation locale (modifica al file degli host del sistema operativo e creazione di un virtual host). LINUX_dominio.conf contiene il virtual host per i sistemi Linux. MAC_httpd.conf contiene il virtual host per i sistemi Mac OS library E' la cartella dedicata alle librerie ed ai framework utilizzati nel progetto _test E' la cartella sulla quale vengono appoggiati tutti i files relativi ai test. E' ulteriormente suddivisa in due sotto cartelle, unit e functional, contenente rispettivamente i test unitari e funzionali web E' la cartella che viene puntata dai virtual host e sulla quale è presente il file index.php 48

57 4 Progettazione del cambiamento di ciascun progetto. Contiene la vera e propria web application, nello specifico tutti i files che vanno resi accessibili all'esterno. La suddivisione dei files all'interno di essa dipenderà dagli specifici progetti _xhtml E' utilizzata dagli sviluppatori per la creazione dei templates dinamici. Contiene la versione statica della web application, ossia tutti i files HTML da utilizzare come modello per lo sviluppo del frontend. Sono il risultato del lavoro del frontend developer, che esegue il montaggio della grafica progettata dal designer Comandi fondamentali Di seguito un riassunto dei comandi messi a disposizione dopo l'aggiornamento di tutte le workstation: Comando phing mysql mysqldump phpunit Descrizione Per eseguire la build del software Per eseguire operazioni sul database Per eseguire il dump del database su file Per eseguire i test automatici Tabella 4.1 Lista dei comandi messi a disposizione su ciascuna worsktation per implementare la Continuous Integration. In questo modo è stato possibile creare un unico script di build standardizzato per tutti client e tutti i progetti, in modo da garantire una configurazione omogenea. 49

58 4 Progettazione del cambiamento Standardizzazione del database Per eliminare i problemi di eterogeneità è stata definita una convenzione sul nome del database da utilizzare per ogni progetto e le credenziali di autenticazione (utente MySQL) con il quale è possibile interagire con esso. In questo modo è stato garanto a ciascuno sviluppatore di gestire il DBMS della propria workstation in autonomia, mantenendo private le proprie credenziali di amministratore, in quanto sono quelle relative al progetto ad essere condivise: l'applicazione, se non diversamente configurata, fa riferimento sempre alle stesse credenziali di accesso al DB. Sono state poi create le procedure SQL necessarie al setup e popolazione del database, ed in seguito salvate nel repository, insieme a tutto il necessario per ottenere tramite un singolo comando: 1. Un utente di progetto attivo e configurato, con le proprie credenziali ed i permessi correttamente configurati per il proprio database. 2. Un database dal nome univoco per il singolo progetto, con la propria struttura ed eventualmente popolato con ben determinati dati iniziali (detti anche fixtures). 4.3 Introduzione del build scripting system E' stato creato un generico file build.xml ed implementati dei target comuni ad ogni 50

59 4 Progettazione del cambiamento progetto. Questo file viene di volta in volta personalizzato secondo le esigenze e posto sotto controllo di versione insieme ad esso. In questo modo ciascuna applicazione ha il proprio script di generazione della build che diventa parte integrante del software e come tale potrà essere migliorato o ampliato di nuove funzionalità. Sono stati definiti due target fondamentali per ciascun progetto: build e make-sql. 1. <?xml version="1.0" encoding="utf-8"?> 2. <project name="e-xtrategy" basedir="." default="build"> 3. <property name="db.name" value="e-xtrategy" /> 4. <property name="db.user" value="root" /> 5. <property name="db.password" value="" /> <target name="build"> 8. <!-- target definition --> 9. </target> <target name="make-sql"> 12. <!-- target definition --> 13. </target> </project> Listato 4.1 Esempio di file build.xml, contenente i target fondamentali build e makesql Il target build Il target build si occupa dell'effettivo setup dell'applicazione automatizzando la gran parte delle attività che altrimenti sarebbero state manuali e soggette ad errore. 51

60 4 Progettazione del cambiamento Tali attività, tipicamente, sono: 1. Cancellazione dei file temporanei ed eliminazione di residui di vecchie build. 2. Impostazione dei permessi di lettura e scrittura nelle directory. 3. Setup del database e dell'utente di accesso tramite le procedure SQL viste precedentemente. 4. Esecuzione di test automatici 1. <target name="build"> 2. <if> 3. <equals arg1="${db.password}" arg2=""/> 4. <then> 5. <property name="pstring" value=""/> 6. </then> 7. <else> 8. <property name="pstring" value="-p${db.password}"/> 9. </else> 10. </if> 11. <exec command="mysql -u${db.user} ${pstring} < _data/$ {db.name}.create.db.sql" checkreturn="true"/> 12. <exec command="mysql -u${db.user} ${pstring} ${db.name} < _data/${db.name}.struttura.sql"checkreturn="true"/> 13. <exec command="mysql -u${db.user} ${pstring} ${db.name} < 14. </target> _data/${db.name}.dati.sql"checkreturn="true"/> Listato 4.2 Esempio di target build con cui viene creato e popolato il database, partendo dai files sql presenti nel repository. 52

61 4 Progettazione del cambiamento Il target make-sql L'applicazione durante il suo funzionamento interagisce con il database inserendo, modificando o cancellando dei record, oppure lo sviluppatore decide di effettuare dei cambiamenti alla struttura di alcune tabelle o della struttura del database in generale. Qualora lo sviluppatore intenda inviare la nuova versione del database al repository è necessario innanzitutto che ne effettui il dump su file. Questa fase è stata automatizzata creando il target make-sql: vengono effettuati il dump della struttura e dei dati e salvati in due distinti files, che andranno a sostituire quelli contenenti le procedure per la creazione e popolazione della vecchia versione del database. 15. <target name="make-sql"> 16. <if> 17. <equals arg1="${db.password}" arg2=""/> 18. <then> 19. <property name="pstring" value=""/> 20. </then> 21. <else> 22. <property name="pstring" value="-p${db.password}"/> 23. </else> 24. </if> 25. <exec command="mysqldump -u${db.user} ${pstring} --skipcomments --no-create-info ${db.name} >_data/${db.name}.dati.tmp" checkreturn="true"/> 26. <exec command="mysqldump -u${db.user} ${pstring} --skipcomments --no-data ${db.name} >_data/${db.name}.struttura.tmp" checkreturn="true" /> 27. <delete file="_data/${db.name}.dati.sql" /> 28. <delete file="_data/${db.name}.struttura.sql" /> 29. <move file="_data/${db.name}.dati.tmp" tofile="_data/$ 53

62 4 Progettazione del cambiamento {db.name}.dati.sql" /> 30. <move file="_data/${db.name}.struttura.tmp" tofile="_data/$ {db.name}.struttura.sql" /> 31. </target> Listato 4.3 Esempio di target make-sql con cui struttura e dati del database vengono fatti persistere su filesystem, prima dell'invio al repository. Una volta effettuata la commit la nuova versione del DB sarà a questo punto presente nel repository. 4.3 Introduzione di uno script di installazione Come illustrato in precedenza, per poter ottenere il funzionamento di ciascun website in locale, sono necessarie alcune operazioni preliminari, che sono la modifica al file degli host del sistema e la creazione di un virtual host per il webserver. Per facilitare l'installazione di ciascun progetto nelle macchine locali è stato creato uno script bash. 1. #!/bin/bash 2. n=$(grep local.e-xtrategy.net /etc/hosts -c) 3. if [ "$n" = 0 ]; then 4. echo local.e-xtrategy.net >> /etc/hosts 5. fi 6. cp LINUX_dominio.conf /etc/apache2/sites-available/ 7. cd /etc/apache2/sites-available/ 8. a2ensite 9. /etc/init.d/apache2 restart Listato 4.4 Esempio di file install.sh, per la modifica del file degli host e la creazione del virtual host. 54

63 4 Progettazione del cambiamento 4.5 Introduzione dei test Per testare l'applicazione nella build privata è stato creato il target test che si occupa di lanciare PHPUnit configurato in modo da eseguire i test che sono stati scritti per l'applicazione. I test automatici, come il file build.xml, vanno considerati parte del software ed anch'essi posizionati all'interno del repository, nella cartella _test: in questo modo una procedura di test scritta da uno sviluppatore va a beneficio di tutto il team che può inoltre rivederla e migliorarla. I test documentano le funzionalità del codice e ne verificano l'effettivo funzionamento: se un requisito del software cambia, anche i test ad esso correlati verranno aggiornati. 1. <?php 2. require_once 'PHPUnit/Framework.php'; 3. require_once APPLICATION_PATH. '/models/user/cgauser.php'; 4. require_once APPLICATION_PATH. '/models/user/cgausers.php'; class CgaUsersTest extends PHPUnit_Framework_TestCase { /** 9. * setup delle fixtures 10. */ 11. public function setup() { 12. $u1 = new CgaUser(); 13. $u1->anno_registrazione = 2009; $u2 = new CgaUser(); 16. $u2->anno_registrazione = 2010; $u3 = new CgaUser(); 19. $u3->anno_registrazione = 2008; $this->_users = array($u1, $u2, $u3); 55

64 4 Progettazione del cambiamento 22. $this->_cgausers = new CgaUsers($this->_users); 23. } /** 26. * testa il risultato dell'operazione su tutta la collection 27. * l'operatore (mock) 28. * che assegna sempre lo stato di confermato 29. */ 30. public function testallsocioperation() { 31. // Create a stub for the CgaUser class. 32. $usermock = $this->getmock('cgauser'); 33. // Configure the stub. 34. $usermock->confirmed = true; //Create a stub for the CgaUserChecker Operator class. 37. $operator = $this- >getmock('cgauserchecker1', array('execute')); 38. // Configure the stub. 39. $operator->expects($this->any()) 40. ->method('execute') 41. ->will($this->returnvalue($usermock)); $this->_cgausers->operation(array($operator)); 44. foreach ($this->_cgausers as $user) { 45. $this->asserttrue($user->confirmed); 46. } 47. } /** 50. * testa il risultato dell'operazione su tutta la collection 51. * l'operatore (mock) 52. * che assegna sempre lo stato di non confermato 53. */ 54. public function testnosocioperation() { 55. // Create a stub for the CgaUser class. 56. $usermock = $this->getmock('cgauser'); 57. // Configure the stub. 58. $usermock->confirmed = false; 56

65 4 Progettazione del cambiamento //Create a stub for the CgaUserChecker Operator class. 61. $operator = $this- >getmock('cgauserchecker1', array('execute')); 62. // Configure the stub. 63. $operator->expects($this->any()) 64. ->method('execute') 65. ->will($this->returnvalue($usermock)); $this->_cgausers->operation(array($operator)); 68. foreach ($this->_cgausers as $user) { 69. $this->assertfalse($user->confirmed); 70. } 71. } /** 74. * testa il risultato di più operazioni sulla collection 75. * il primo operatore assegna sempre lo stato di confermato 76. * il secondo operatore assegna sempre l'anno */ 78. public function testmultipleoperations() { 79. // Create a stub for the CgaUser class. 80. $usermock = $this->getmock('cgauser'); 81. // Configure the stub. 82. $usermock->confirmed = true; //Create a stub for the CgaUserChecker Operator class. 85. $op1 = $this- >getmock('cgauserchecker1', array('execute')); 86. // Configure the stub. 87. $op1->expects($this->any()) 88. ->method('execute') 89. ->will($this->returnvalue($usermock)); $usermock2 = clone $usermock; 92. $usermock2->anno_registrazione = 2010; //Create a stub for the CgaUserChecker Operator class. 57

66 4 Progettazione del cambiamento 95. $op2 = $this- >getmock('cgauserchecker1', array('execute')); 96. // Configure the stub. 97. $op2->expects($this->any()) 98. ->method('execute') 99. ->will($this->returnvalue($usermock2)); $this->_cgausers->operation(array($op1, $op2)); 102. foreach ($this->_cgausers as $user) { 103. $this->asserttrue($user->confirmed); 104. $this->assertequals(2010, $user- >anno_registrazione); 105. } 106. } 107. } Listato 4.5 Esempio di batteria di test unitari per una classe, scritti utilizzando il framework di test PHPUnit. 4.6 Installazione del server di Continuous Integration Il server di Continuous Integration Hudson è stato installato nella stessa macchina su cui è presente il repository SVN. La scelta di accorpare le due entità anziché tenerle separate è stata fatta in ottica di una diminuzione di carico della rete LAN, Hudson infatti ad ogni build scarica per intero i progetti da integrare: data l'entità del traffico si è preferito passare direttamente per l'hard disk per non influenzare negativamente le prestazioni ed ottenere un feedback rapido. Hudson è stato poi configurato in modo da effettuare dei polling verso il repository SVN ed individuare eventuali cambiamenti: qualora ve ne fossero scarica il codice del 58

67 4 Progettazione del cambiamento progetto e ne effettua la build utilizzando lo stesso script di build degli sviluppatori, mostrando l'esito delle operazioni sulla propria dashboard. 4.7 Training del personale Prima di terminare l'opera di installazione e configurazione dei client e del server di Continuous Integration si è proceduto con la formazione degli sviluppatori per l'utilizzo del nuovo ambiente. La Continuous Integration è infatti anzitutto una pratica che funziona solamente se viene rispettata ed è importante fare in modo che tutti gli sviluppatori prendano coscienza di quali cambiamenti implicherà nel processo di sviluppo software e delle relative motivazioni Lezioni frontali E' stata redatta una presentazione riguardante i temi della Continuous Integration, delle pratiche su cui si basa e dei problemi che si prefigge di risolvere. Successivamente si è passato ad una lezione frontale, alla quale hanno partecipato tutti gli attori coinvolti nello sviluppo software. Sono stati toccati in particolar modo i temi chiave che presentavano un più immediato beneficio per l'azienda, come ad esempio l'integrazione e l'automatizzazione del database. 59

68 4 Progettazione del cambiamento Redazione di documenti operativi Tutto il materiale visto a lezione è stato messo a disposizione del team di sviluppo e salvato nel wiki aziendale. E' stato redatto inoltre un documento dai toni informali, successivamente appeso in bacheca, per non far perdere l'attenzione circa le nuove tematiche introdotte. Il contenuto del documento è un veloce riassunto delle bestpractises della Continuous Integration, accompagnato da una breve guida che permette di iniziare a lavorare sin da subito con il nuovo ambiente Post sul corporate blog E' stato pubblicato un post 15 sul corporate blog dell'azienda in cui viene spiegata a grandi linee la pratica della Continuous Integration e di come sia importante organizzare il lavoro nel team di sviluppo. Lo scopo della pubblicazione del post è stato quello di mandare un segnale, sia all'interno che all'esterno, della presa di coscienza che il successo o l'insuccesso di un sistema informativo non è solamente decretato dalla tecnologia che utilizza, ma anche da come questa è organizzata all'interno dell'azienda e dal rispetto delle buone pratiche di utilizzo. 15 Continuous Integration: quando la pratica va oltre gli strumenti, Giorgio Mandolini, e-xtrategy s.r.l. 60

69 5 Risultati ottenuti 5 Risultati ottenuti Questo capitolo descrive i risultati ottenuti a seguito dei cambiamenti introdotti nel capitolo 4, focalizzando l'attenzione, punto per punto, sui problemi riscontrati nel capitolo 3. In questa fase verranno espresse infine delle conclusioni sul lavoro svolto ed eventuali sviluppi futuri. 5.1 Soluzione del problema degli environment eterogenei L'utilizzo di una convenzione sulle modalità di installazione e configurazione dei progetti ha portato ad una considerevole diminuzione dei problemi di configurazione delle applicazioni. Oltre a ciò lo script di build, grazie alla possibilità di essere parametrizzato, si è dimostrato una strada molto efficace per uniformare anche client all'apparenza 61

70 5 Risultati ottenuti eterogenei: esso è stato utilizzato infatti sia su macchine Linux che Mac OS, oltre che in macchine Windows, queste ultime approntate solamente a scopo didattico. Anche il server di Continuous Integration utilizza il medesimo script di build per costruire le applicazioni in maniera automatica: in questo modo si è riusciti ad ottenere la garanzia che tutte le operazioni di installazione e configurazione dei lavori vengono effettuate in maniera identica e ripetibile su ogni macchina, ed il software presente nel repository è già pronto per essere rilasciato in produzione. Quello che inizialmente era un problema di riconfigurazione manuale e dispendiosa è diventato il lancio di un unico comando da shell: l'unico onere dello sviluppatore è di fornire eventuali parametri e credenziali di accesso differenti da quelli di default, qualora sia necessario. 5.2 Soluzione del problema di integrazione del codice L'utilizzo di test automatici fornisce una rapida indicazione sul funzionamento del software una volta effettuate delle modifiche ed integrate con il lavoro del resto del team. Come imposto dalla pratica non si può inviare codice al repository se questo non è prima stato verificato da test automatici ed il feedback fornito in seguito dal Continuous Integration server è una seconda prova sull'avvenuta integrazione. I benefici dell'introduzione dei test automatici sono evidenti, ma al tempo stesso 62

71 5 Risultati ottenuti l'effettiva messa in atto di questa buona pratica è il compito che richiede più tempo in azienda. I test automatici infatti necessitano di tempo per essere scritti e vanno visti come un investimento: scrivere una volta un test assicura per sempre che una determinata funzionalità sia testata ed evita il presentarsi due volte dello stesso bug. Oltre a ciò, l'introduzione di test automatici o pratiche di sviluppo come la Test Driven Development (TDD), che si basano su di essi, richiedono un'iniziale curva di apprendimento che durante lo svolgimento del presente lavoro, vista la molteplicità degli argomenti da trattare, non è potuta essere del tutto affrontata. I test automatici sono stati comunque introdotti ed implementati in via sperimentale su alcuni progetti: l'impatto che hanno avuto su di essi è stato giudicato positivo e per questo l'azienda vede il loro utilizzo a regime come un investimento da fare nel prossimo futuro. 5.3 Soluzione del problema della visibilità di progetto La visibilità di progetto ha subito un sensibile miglioramento grazie alla dashboard fornita dal Continuous Integration server. Lo sviluppatore a colpo d'occhio è in grado di monitorare lo status di tutti i progetti seguiti dall'azienda e capire subito se su alcuni di essi vi sono problemi in corso. 63

72 5 Risultati ottenuti Figura 5.1 Dashboard fornita dal C.I. server Hudson. Il verde indica una build funzionante mentre il rosso segnala la presenza di problemi. Figura 5.2 Dettagli relativi ad un progetto, comprensivi della code coverage dei test unitari. 64

73 5 Risultati ottenuti Figura 5.3 Andamento di una build nel tempo. Figura 5.4 Dettagli relativi alla copertura del codice. 65