Strumenti di Build Automation - Jenkins

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del Software Strumenti di Build Automation - Jenkins Anno Accademico 2016/2017 Candidato: Simone Borrelli matr. N

2 Sommario Introduzione... 2 Strumenti di Build Automation Make ANT Maven POM File di Configurazione Gestione delle Dipendenze Ereditarietà Gradle Struttura Gestione delle dipendenze La Continuous Integration - Jenkins Cos è l integrazione continua? Test Driven Development Continuous Integration Continuous Development Continuous Integration: Le Tecnologie Jenkins Installazione e configurazione I Job di Jenkins Esempio Esempio #2 Jenkins & Maven Dalla Continuous Integration al Continuous Deployment User Acceptance Test Conclusione e Sviluppi Futuri Bibliografia

3 Introduzione Nel contesto dello sviluppo del software, la creazione si riferisce al processo che converte file e altre attività sotto la responsabilità degli sviluppatori in un prodotto software nella sua forma finale o consumabile. In particolare, i tools per la build automation ci permettono di automatizzare alcune attività del ciclo di vita di un software, tra cui: Compilazione: operazione di traduzione di una serie di istruzioni scritte in un determinato linguaggio di programmazione (codice sorgente) in istruzioni in codice binario (codice oggetto), leggibili della macchina; Linking: consiste nel procedimento di integrazione dei vari moduli a cui un programma fa riferimento con lo scopo di creare una singola unità eseguibile; Packaging dei binari: il risultato della compilazione deve assumere una forma compatta ed una chiara connotazione in base al suo scopo: eseguibile, libreria da esportare, etc.; Esecuzione di test: per evitare bug, è necessario attuare una fase di sperimentazione che dimostri l affidabilità del software in ogni sua sfaccettatura, cercando di verificarne le funzionalità in ogni possibile situazione; Distribuzione della soluzione software: una volta che il software è il pronto, deve essere installato e configurato sui sistemi per la quali è stato implementato; Creazione di documentazione: data la complessità dei prodotti informatici, è fondamentale la redazione di opportuni documenti che ne spieghino l utilizzo e le funzionalità; 2

4 I prodotti di build automation sono tools utilizzati per automatizzare tutte le fasi appena descritte Tramite un efficace codice di build automation è possibile: Eliminare una fonte di variazione e quindi di difetti. Un processo di compilazione manuale contenente un gran numero di passaggi necessari offre tante possibilità di errore; Migliorare la qualità del prodotto; Accelerazione i tempi di compilazione e della fase di collegamento; Generare e deployare 1 automaticamente diverse versioni del programma; Reperire automaticamente le risorse necessarie a completare l esecuzione del programma; Per rendere l elaborato più leggibile, ho deciso di dividerlo in due punti principali, ovvero: 1. Analisi degli strumenti di Build Automation più importanti, indicandone vantaggi e svantaggi; 2. Nel secondo punto mi concentrerò sullo strumento Jenkins, andando a sviluppare l argomento sotto diversi punti; 1 Il deployment indica la consegna o rilascio al cliente, con relativa installazione e messa in funzione di una applicazione o strumento software 3

5 Strumenti di Build Automation 1.1 Make L origine di Make risale al 1977, creato da Stuart Feldman. Prima dell invenzione di make il sistema di build di UNIX consisteva semplicemente in make e install, ovvero, semplici shellscript, insieme al codice sorgente di un programma. Il Make è una utility sviluppata sui sistemi operativi della famiglia UNIX, che automatizza il processo di creazione di file che dipendono da altri file, risolvendo le dipendenze e invocando programmi esterni per il lavoro necessario. Sotto il nome make è possibile raggruppare molte utility diffuse sui vari sistemi Linux o Windows. La più nota è GNU Make. La gestione delle dipendenze in make è molto semplice, si utilizza un meccanismo di controllo tale da confrontare ogni modulo con la sorgente o con i file intermedi da cui esso deriva; se tali file hanno subito qualche modifica dall ultima compilazione, essi vengono ricompilati. Per determinare se un file è non aggiornato rispetto alle sue fonti, Make confronta la data di modifica del modulo con quella del file di dipendenza. Una volta definite le dipendenze esse vengono processate dal programma Make che si occupa di eseguire le istruzioni nel Makefile. Il Makefile è uno script in un linguaggio dichiarativo, non imperativo, che permette di specificare come debbano avvenire le operazioni di deployment e installazione di un software. 4

6 Esso contiene una serie di ricette per generare dei file a partire da altri file. Tali ricette hanno questo formato: target : prerequisiti ricetta Il target può essere il nome di un file generato da un programma, oppure un nome arbitrario di un azione da eseguire. Lanciando Make senza specificare il target verrà eseguito il primo target del file. Per questo, se si vuole eseguire più target col semplice make conviene usare un phony target 2 che li comprenda tutti. Tradizionalmente questo target viene chiamato all, ma potrebbe avere qualsiasi altro nome. L importante è che sia il primo target del Makefile. Esempio: all: target1 target2 target3 Uno degli aspetti più importanti da gestire sono i prerequisiti, in quanto Make serve anche a ridurre le operazioni non necessarie. Voglio che un certo target sia eseguito solo quando vengono modificati alcuni file. Per non dover aggiungere esplicitamente tutti i file da cui dipende il target, si usano delle scorciatoie (ad esempio wildcar). Tra gli svantaggi del Make abbiamo che: Esistono poche altre possibilità di implementare strutture di controllo nell ambito di un Makefile; Make dipende dal sistema operativo: con sistemi operativi diversi non è possibile riutilizzare identicamente gli stessi script, in quanto questi dipendono dal linguaggio di Shell; 2 I phony target sono target fittizi inseriti per provocare l esecuzione del comando in ogni caso 5

7 1.2 ANT Apache Ant (Another Neat Software) è stato concepito da Apache Tomcat agli inizi del È simile a Make, ma scritto in Java. Ant nasce soprattutto con l intento di sostituire Make, in quanto esso sopperisce ai sui difetti. Come abbiamo spiegato nel paragrafo precedente, il maggior difetto di Make era, infatti, la non portabilità. Ant risolve tale problema fornendo una grande quantità di funzionalità incorporate in modo tale da avere lo stesso comportamento su tutte le piattaforme. Tra i vantaggi offerti da ANT dobbiamo andare a nominare soprattutto il fatto che esso può essere richiamato da linea di comando, in modo da poter essere facilmente integrato in altri programmi ed inoltre non necessita di installazione in quanto è sufficiente copiare i file ed eventualmente, settarne il percorso tra i path predefiniti. Ant, inoltre, è abbastanza flessibile, ma non dà alcuna indicazione su come strutturare il progetto e rende ogni script di build unico e difficile da comprendere. Tuttavia, dopo la sua versione iniziale, ANT è stato migliorato con la possibilità di installare plug-in. I comandi che Ant esegue sono letti da file XML. In tale file bisogna definire: Le operazioni disponibili, ovvero i target; Per ciascuna delle operazioni, i comandi da eseguire, ovvero i task; Da ciò possiamo capire che, praticamente, la sintassi sarà la stessa del Make. Il maggior inconviente di ANT è proprio l utilizzo di XML: esso sarà efficiente per la descrizione dei dati in modo gerarchico, poiché si basa su una struttura di tipo gerarchica, ma la sua efficienza andrà a scemare nell esprimere il flusso del programma 6

8 e la logica condizionale. Tuttavia, nonostante gli evidenti vantaggi introdotti tramite ANT, anche esso soffre di alcune limitazioni, ovvero: Nella maggior parte dei casi, gli script ant sono generati automaticamente da altri programmi, ad esempio da IDE come Eclipse; Gli script ant sono limitati, in quanto a strutture di controllo e ad altre possibilità di introdurre comportamenti dinamici; Gli script ant possono indirizzare soltanto file su disco, non risorse remote; 1.3 Maven Maven è un software usato non unicamente per la gestione di progetti di build automation, ma anche per la gestione di progetti Java. In particolare fu pensato per unificare il modo di sviluppare e organizzare diversi progetti della famiglia Apache. Per funzionalità è molto similare ad ANT, ma basato su concetti differenti. Maven non si occuperò soltanto della costruzione, installazione e deployment dei progetti, ma anche della generazione della documentazione, di metriche, reports e casi di test inoltre è un valido strumento in quanto esso si basa sull applicazione di modelli per realizzare un infrastruttura che mostra le caratteristiche di visibilità, riutilizzabilità, manutenibilità e comprensibilità. Il soddisfacimento di tali caratteristiche è importante in quanto, senza di esse, è altamente improbabile che più persone riescano ad elaborare produttivamente insieme. 7

9 Anche Maven, come Ant legge uno o più file XML di configurazione, tuttavia, Maven ignora completamente tutti quei punti dolorosi creati da ANT, e mira a risolvere un problema completamente diverso. Maven gestisce il ciclo di vita del software, dalla scrittura del codice al deploy in ambiente di produzione. Le fasi standard di Maven sono: 1. Validate; 2. Generate-Sources; 3. Process-Sources; 4. Generate-Resources; 5. Process-Resources; 6. Compile; 7. Process-test-sources; 8. Process-test-resources; 9. Test-Compile; 10. Test; 11. Package; 12. Install; 13. Deploy 8

10 1.3.1 POM 3 File di Configurazione È una rappresentazione XML di un progetto Maven, contenuto in un file nominato pom.xml, che contiene informazioni sul progetto e dettagli sulla configurazione utilizzata da Maven per costruire il progetto. Il POM contiene anche informazioni sugli obiettivi e plugins. Mentre sta eseguendo un task o un obiettivo, Maven va alla ricerca del POM nella directory corrente. Maven legge il POM, estrae le informazioni di configurazione di cui ha bisogno, e poi esegue l obiettivo. Alcune delle configurazioni che è possibile specificare nel POM sono: Dipendenze del Progetto; Plugins; Goals; Build Profiles Versione del progetto Sviluppatori Mailing List Prima di creare un POM, abbiamo bisogno di decidere prima il groupdid (identificatore del gruppo), il suo nome, artifactid (identificatore del manufatto) e la sua versione, in quanto tali attributi aiutano a identificare unicamente tale progetto nella repository. Di questi, I primi due possono essere ereditati da un POM genitore. 3 Project Object Model 9

11 Ad esempio: Gestione delle Dipendenze Come abbiamo già specificato in precedenza, una delle innovazioni più importanti portata da Maven è la gestione delle dipendenze. Le coordinate di un progetto sono un elemento molto importante poiché costituiscono il criterio utilizzato da Maven per referenziare I vari progetti. Queste, per esempio sono necessarie per gestire il grafo delle dipendenze, area che tradizionalmente ha creato non pochi problemi nell elaborazione dei script di build. In effetti, la quasi totalità dei progetti, per poter essere costruiti e eseguiti correttamente, necessità di includere opportune librerie sia appartenenti al progetto stesso sia fornite da terze parti. La sincronizzazione delle varie librerie, il prelievo della versione corretta, la relativa distribuzione sono aspetti che da sempre hanno complicato il processo di build dei vari progetti. Maven è in grado di gestire queste problematiche attraverso la lista delle dipendenze, effettuando il download automatico dei manufatti richiesti ed effettuando i collegamenti necessari durante le varie fasi. Maven risolve automaticamente eventuali dipendenze transitive, ossia esegue la stessa procedura anche per eventuali dipendenze della libreria presente nella lista delle dipendenze del progetto in esame. 10

12 1.3.3 Ereditarietà Un altra caratteristica molto potente e unica di Maven è la possibilità di relazionare tra loro i progetti con legami di ereditarietà. I file POM di Maven prevedono nativamente la possibilità di dichiarare tale relazione. I progetti genitori e quelli esclusivamente aggregabili devono specificare il valore POM all interno del campo packaging. Questo campo serve per specificare la natura del manufatto prodotto (Per default Maven suppone che si voglia generare un file JAR). 1.4 Gradle Gradle è un sistema open source fondato sulle idee di Apache Ant e Apache Maven, esso è stato ideato e realizzato da Hans Dockter, fondatore della compagnia Gradle. Gradle introduce un domainspecific language (DSL) basato su Groovy, al posto della modalità XML usata da Maven e Ant per dichiarare la configurazione del progetto. Gradle è stato progettato per sviluppi multi-progetto che possono crescere fino a divenire abbastanza grandi e sopporta sviluppi incrementali determinando in modo intelligente quali parti del build tree sono aggiornate, in modo che tutti I processi che dipendono solo da quelle parti non avranno bisogno di essere rieseguiti; così facendo, il software riduce significativamente il tempo di costruzione del progetto, in quanto, durante il nuovo tentativo di costruzione, verranno eseguite solo le attività il cui codice è effettivamente stato alterato a partire dall ultima costruzione del progetto per processi concorrenti, il che consente di svolgere alcuni compiti, durante la costruzione, in parallelo su più core delle medesima CPU, su più CPU o su più computer. 11

13 Il software integra in sé alcuni punti di forza di Apache Maven, ovvero: convenzione sulla configurazione, ciclo di vita, gestione delle dipendenze nello stile di Apache Ivy o Maven e l utilizzo di repository. Gradle offre I seguenti vantaggi: Possibilità di definire il meccanismo di costruzione in linguaggio Groovy, nel file build; Possibilità di modificare il comportamento di alcune attività; Una notazione compatta per descrivere le dipendenze; Un motore di produzione progettato per ottenere progetti multilingue; Struttura La struttura di Gradle è costituita da un nucleo astratto e da una serie di plugin che ne espandono le funzionalità. Anche la costruzione dei progetti Java avviene per mezzo di un plugin. Gradle include alcuni plugin ufficiali che consentono la costruzione di progetti Java, Groovy, Scala e C++; inoltre è supportata la costruzione degli Java Enterprise Archive (gli archivi WAR ed EAR). Il processo di costruzione di Gradle si suddivide in due fasi principali: 1. Configurazione; 2. Esecuzione; Durante la configurazione, vengono delineati I passi dell intera costruzione per generare il grafico di dipendenza che contiene la sequenza di tutte le fasi da eseguire. Durante l esecuzione, invece, si attraversano le attività precedentemente rilevate. 12

14 Gradle utilizza tre file principali per personalizzare la costruzione: build.gradle (necessario); settings.gradle (opzionale) gradle.properties (opzionale) Il file setting.gradle contiene la definizione dei moduli di cui si compone il multi-progetto. Il file gradle.properties contiene un elenco di valori validi per l inizializzazione delle proprietà di uno specifico progetto Gradle Gestione delle dipendenze La gestione delle dipendenze è una caratteristica critica, e Gradle ha posto una particolare enfasi sull offrire meccanismi che permettono di gestire la dipendenza sia in modo semplice, e sia compatibile con un numero molto ampio di approcci. La capacità di Gradle di gestire le dipendenze non si limita all utilizzo di librerie esterne, poichè se gli elementi DSL standard non si adattano alle esigenze del progetto, si può anche definire un vocabolario proprio attravero l utilizzo delle estensioni di Gradle. Un requisito fondamentale è la riproducibilità, ovvero se è possibile riprodurre il programma su una nuova macchina. Per risolvere tale problema, Gradle considera ciascuno dei moduli di un progetto di grandi dimensioni, un progetto separato il quale può definire le dipendenze a librerie esterne o altri moduli. Inoltre, ogni sottoprogetto può essere eseguito singolarmente. Gradle, quindi, capisce quale sottoprogetto richiede la ricostruzione delle dipendenze, senza dover memorizzare artefatti nella cache locale. 13

15 È facile capire che, ogni volta che si inizia un nuovo processo in Gradle, il caricamento di tutte le sue dipendenze interne e l esecuzione della logica di build, richiedono un paio di secondi prima che inizi ad eseguire. Per migliorare le prestazioni di avvio, Gradle può essere eseguito in modalità demone 4. In modalità demone, Gradle, non esegue solo la build, ma mantiene l esecuzione in background, così invocazioni di build successe saranno sulle spalle del processo daemon esistente. 4 Programma eseguito in background, senza che sia sotto il controllo diretto dell utente. 14

16 La Continuous Integration - Jenkins 2.1 Cos è l integrazione continua? L integrazione continua è una pratica che si applica in contesti in cui lo sviluppo del software avviene attraverso un sistema di versioning. Consiste nell allineamento frequente 5 degli ambienti di lavoro degli sviluppatori verso l ambiente condiviso. Il concetto è stato originariamente proposto nel contesto dell extreme programming, come contromisura preventiva per il problema dell integration hell 6. L integrazione continua è stata originariamente concepita per essere complementare rispetto ad altre pratiche, in particolare legate al Test Driven Development. In particolare, la CI viene spesso applicata in ambienti in cui siano presenti sistemi di build automatica e/o esecuzione automatica di test, come Jenkins. 2.2 Test Driven Development Si tratta di una pratica concettualmente semplice, basata sullo sviluppo del software a partire dai test automatici. Nel TDD si sviluppa prima il codice di test, e successivamente il codice applicativo vero e proprio della funzionalità da implementare. Ciò è svolto attraverso diversi strumenti e con una precisa progressione di test falliti e superati. 5 Più volte al giorno 6 Tutte le difficoltà dell integrazione di porzioni software sviluppati in modo indipendente su lunghi periodi di tempo 15

17 Grazie a tecnologie come i framework di mock, è possibile fare test che verifichino condizioni di malfunzionamento particolare, per esempio problemi di rete, oppure eccezioni derivanti dal file system. Tali possibili situazioni vanno prese in considerazione già in fase di sviluppo per non avere problemi in fase di produzione. È possibile, poi, conoscere quanti e quali test sono stati effettuati, per avere un idea globale del livello di copertura dei test sull applicazione 2.3 Continuous Integration Prima di effettuare una modifica sul codice sorgente, uno sviluppatore prende una copia del codice corrente sulla quale lavorare. Man mano che gli altri sviluppatori fanno modifiche sul repository, la copia smette di rappresentare il codice del repository. Le modifiche non si riflettono unicamente sul codice, ma anche sulle librerie ed altre risorse che possono creare dipendenze e potenziali conflitti. Più è lungo il tempo durante il quale un branch di codice rimane scaricato, maggiore è il rischio di conflitti di integrazione quando il branch viene reintegrato nel repository. Quando gli sviluppatori vogliono sottomettere il codice, devono prima aggiornare le proprie copie locali del codice con i cambiamenti che sono stati fatti al repository dal momento in cui loro hanno aggiornato la copia locale. Più modifiche sono state fatte e più lavoro è necessario fare prima di sottomettere le proprie modifiche. È possibile che il repository sia diventato così diverso dalla copia locale dello sviluppatore che il tempo necessario per integrare le proprie modifiche con quelle fatte dagli altri superi il tempo necessario a fare le modifiche. L integrazione continua è un processo che consiste nell integrare presto e spesso, limitando le possibilità dell integration hell. 16

18 2.4 Continuous Development Un ulteriore passo avanti è rappresentato dal Continuous Development, termine utilizzato per descrivere i diversi aspetti del processo iterativo di sviluppo software che include, appunto, l integrazione continua, il rilascio continuo, il test continuo e il deploy continuo. Il concetto alla base è molto semplice: invece di attendere e inglobare molti cambiamenti, si preferisce rilasciare una versione aggiornata con cambiamenti minimi, ogni volta che una modifica sia stata positivamente implementata e sia pronta. 2.5 Continuous Integration: Le Tecnologie La Continuous Integration prevede l adozione di un server per l integrazione continua, come ad esempio Cruise Control, Jenkins o Bamboo. L importante è che vengano fornite alcune funzionalità fondamentali: Controllare il repository del codice sorgente e verificare ogni check-in; Effettuare il check-out del codice sorgente in conseguenza di ogni check-in; Effettuare la build del codice sorgente; Eseguire i casi di test; Lanciare eventuali build secondarie; In tale elaborato ci concentreremo su Jenkins. 17

19 2.6 Jenkins Jenkins è un tool di integrazione continua, è scritto in Java ed è Open Source. Egli nasce come alternativa ad Hudson. Viene eseguito lato server, all interno di un server web che supporta la tecnologia Servlet, quindi può essere acceduto da remoto, tramite un normale browser. È compatibile con gran parte dei tool con cui si gestisce il codice sorgente: Concurrent Version System, Subversion, Git, Mercurial, AccuRev e altri ancora. È inoltre in grado di eseguire progetti realizzati in Ant o Maven. Può essere mandato in esecuzione sia in sincrono con ogni commit che ad intervalli di tempo prestabiliti. Grazie alla sua architettura open, sono nati per Jenkins molti plugin, che consentono l utilizzo dello stesso con diverse suite di creazione di test automatizzati: JUnit, invece, è supportato nativamente. Perché Jenkins? Come abbiamo già detto, Jenkins sarà installato su un server su cui tutto l accumulo avrà luogo. Jenkins inoltre sarà: Semplice da utilizzare Estensibile Scalabile Flessibile Open Source 18

20 2.6.1 Installazione e configurazione Essendo Jenkins una web application ci sono diversi modi per installare il server: Tutti i sistemi: lancio manuale dell eseguibile java - jenkins.war; *nix: installazione da precompilato; Servlet container: il.war può essere deployato all interno di un web server che supporti Servel 2.4/JSP 2.0 o seguenti; È utile installare Jenkins come servizio separato anche nei casi in cui la macchina abbia un servlet container, questo è utile anche per poter filtrare il traffico in ingresso e limitare l accesso a Jenkins direttamente dal firewall. Una volta installato in servizio sarà possibile osservare i file di configurazione nelle seguenti directory: Windows: C:\Program Files (x86)\jenkins; Debian/Ubuntu: /etc/default/jenkins; *nix: /var/lib/jenkins; Appena connessi tramite browser alla porta configurata, sarà possibile trovare la schermata home: 19

21 Tra le prime impostazioni di Jenkins è possibile notare: # of executors: rappresentano il numero di job eseguibili contemporaneamente nel nodo, il valore di default è 2; Jenkins Location: è l URL pubblica di Jenkins stesso: <indirizzo IP>:<porta>; Maven Configuration: per poter eseguire job di tipo Maven è necessario averne installata almeno una versione; JDK: elenco delle JDK da rendere disponibili come compilatori per i job; I Job di Jenkins Dopo le dovute configurazioni possiamo passare alla creazione di un job. I job di Jenkins possono essere di diversi tipi, ma i principali sono 2: 1. Maven job: Un job che comprende come passo principale l invocazione di Maven con un apposito pom.xl. Le fasi di un job di tipo Maven sono: Lettura dei parametri di input; Gestione del codice sorgente; Pre-build Steps; Maven build; Post-build Steps; Azioni dopo la build; Tutte le fasi sono opzionali (Tranne la fase Maven) e i plugin contribuiscono ad arricchire gli steps con molte funzionalità aggiuntive. Ciascuno step che non venisse completato con successo può far fallire l intero Job; 2. Generic job: Un job che non prevede un passo principale. È utile per eseguire operazioni diverse dalle build come invocare script shell o eseguire plugin specifici; 20

22 Un tipico job orientato alla Continuous Integration, prende in input una stringa con il nome di un tag o di un branch e recupera i sorgenti corrispondenti copiandoli nella cartella del job dentro il workspace di Jenkins. Esegue poi l invocazione di Maven in quell ambiente, con le opzioni e goal predisposti. 21

23 2.7 Esempio Prerequisiti: La prima cosa di cui abbiamo bisogno è che la Java JDK sia installata. Quindi andremo a verificare l installazione tramite il comando: java -version Il quale risultato sarà: Configurare Tomcat: Jenkins sarà disponibile come file con estensione.war, quindi abbiamo bisogno di fare il deploy. Per fare ciò, la prossima cosa da fare sarà quella di configurare un server Tomcat. Per fare ciò basterà avviare il file startup.bat e aspettare l esecuzione del file, che alla fine dovrà mostrare un messaggio del tipo: Ora, andando all indirizzo sarà possibile vedere: 22

24 Creazione del Job: Il nostro obiettivo sarà quindi creare un job che mi permetterà di stampare a video un semplice Hello, World. Innanzitutto, quello che dobbiamo fare, è creare un file Java, che mi permetterà di stampare a video la frase Hello, World : Tale file andrà salvato nella directory del workspace di Jenkins:.jenkins\workspace. Ora dobbiamo configurare Jenkins per un nuovo Job, che chiameremo HelloWorld. Nella sezione Gestione Codice Sorgente dovremo indicare in quale percorso si andrà a prelevare il file. 23

25 Nella sezione Build dovremo indicare di voler eseguire un comando batch Windows, ovvero: Javac HelloWorld.java Java HelloWorld Una volta finita la configurazione, basterà effettuare la build e aspettare il risultato della compilazione, che in questo caso sarà: 24

26 2.8 Esempio #2 Jenkins & Maven In questo secondo esempio andremo a mostrare l integrazione di Jenkins con Maven. Il nostro obiettivo sarà quello di mostrare la JUnit test integration utilizzando Maven come strumento di build e utilizzare una notifica nel caso di build fallita. Prerequisiti: Per l esempio in questione utilizzeremo i seguenti strumenti: 1. JDK versione ; 2. Maven versione 3.5.0; 3. Git; Creazione del Job: Il nostro obiettivo sarà quello di generare un ID unico e andare a svolgere dei test, per controllare che non ci siano due numeri uguali, tramite JUnit. Dobbiamo andare a configurare il nostro Job: Preleviamo il codice da: Quindi dovremo configurare in questo modo: 25

27 Il codice prelevato sarà il seguente: Dove, tramite generateuniquekey() andremo a generare l ID, e tramite randomuuid().tostring() lo renderemo di tipo Stringa. Per quanto riguarda la configurazione di Maven, invece: E per il test JUnit: 26

28 Per il test JUnit utilizzeremo la seguente classe: Tramite il metodo assertequals(int expected, int actual) asseriamo che l intero che ci aspettiamo sia uguale all intero effettivo che stiamo considerando. Assert mostrerà un messaggio di errore soltanto quando l asserzione fallirà. Il risultato sarà il seguente: Per quanto riguarda l invio della mail, in caso di build fallita, basterà aggiungere nel campo Azioni dopo la build l azione Notification e indicare l indirizzo alla quale si dovrà inviare la notifica. 27

29 Supponiamo di fare un errore nella build del progetto, in fase di compilazione avremo il seguente risultato: Infatti, controllando la mail indicata, abbiamo: 28

30 2.9 Dalla Continuous Integration al Continuous Deployment Una volta scritto il codice, i test automatici lo hanno condotto a destinazione e hanno consentito di rimuovere i bug. Possiamo ora utilizzare il framework di Continuous Integration prescelto, poiché è in grado di effettuare una build e di effettuarne il deployment nell ambiente UAT User Acceptance Test UAT sta per User Acceptance Test, ossia quei test che si rivolgono all utente finale, che non dovrà più valutare gli aspetti strettamente programmatici, ma verificare che le soluzioni adottate funzionino. In pratica tali test vanno a replicare quello che si farebbe con quell applicazione in uno scenario reale di utilizzo, quindi servono come verificare finale che le funzionalità previste nei requisiti vengano soddisfatte. Una volta che il processo di UAT è stato completato, siamo pronti per l approvazione della vera e proprio release. 29

31 Conclusione e Sviluppi Futuri In tale elaborato ho analizzato alcuni dei tools per la Build Automation andando ad analizzare pregi e difetti. Abbiamo iniziato con Make, andandone ad analizzare i punti di forza, poi siamo passati ad Ant, che prende in concetti introdotti da Make e li porta ad un livello successivo, andando a limare alcuni difetti di Make. Evoluzione di tale strumento è Maven che non si occuperà soltanto della costruzione, installazione e deployment dei progetti, ma anche della generazione della documentazione, di metriche, reports e casi di test. Infine abbiamo analizzato Gradle, studiandone la struttura e gestione delle dipendenze. Il punto fondamentale, tuttavia, è la Continuous Integration e Jenkins. Uno degli obiettivi sia per il development che per le operations è quello di rilasciare nuove versioni delle applicazioni in tempi brevi: quindi, i tempi di aggiornamento annuali sono ormai sorpassati, per dare spazio al deploy di nuove feature e versioni su base settimanale (o addirittura quotidiana). Infatti, se una nuova funzione è ben identificata e implementata può essere messa a disposizione degli utenti immediatamente. Resta però il problema di come sia possibile testare in maniera adeguata un applicazione di grandi dimensioni, nella visione di uno sviluppo veloce. Tale difficolta viene risolta proprio dalla Continuous Integration. Eventuali sviluppi futuri di tale elaborato mi consentirebbero di approfondire alcuni aspetti che sono stati trascurati. 30

32 Ad esempio, si potrebbero approfondire meglio i concetti che riguardano il Continuous Deployment. Possiamo ad esempio parlare della gestione della configurazione con Chef, strumento scritto in Ruby e in Erlang, potente e versatile, utilizzato da grandissime aziende: Mozilla, Facebook, HP. Chef si può integrare con piattaforme cloud, per effettuare in maniera automatica il provisioning e la configurazione di nuove macchine, sia fisiche che virtuali. Inoltre, potrei inserire altri esempi di Job in Jenkins, che andrebbero ad utilizzare diversi plugin, come ad esempio Blue Ocean o Subversion Plugin, che permettono di espandere le funzionalità di Jenkins per molteplici utilizzi. 31

33 Bibliografia [1]. Porfirio Tramontana, Lucidi del corso di Ingegneria del software II, Cdl Ing.Informatica, Università degli Studi Federico II Napoli, a.a. 2014/15. [2]. [3]. [4]. [5]. tegration_software [6]. [7]. 32