Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee

Università degli Studi di Trieste

Facoltà di Ingegneria

Tesi di Laurea Triennale in Ingegneria Informatica

Studio e Realizzazione di un SW per la gestione dei profili e delle versioni di applicazioni web

in ambiente JEE.

Relatore: Laureando:Prof. Maurizio FERMEGLIA Francesco FERONT

Anno Accademico: 2009/2010

Pag. 1/39

A me stesso.

Fanculo tutti!

1 - Introduzione Pag. 2/39

Indice generale1 - Introduzione.................................................................................................................42 - Sommario.....................................................................................................................53 - Analisi...........................................................................................................................6

3.1 - Maven...................................................................................................................63.1.1 - Struttura dei file Pom.xml.............................................................................73.1.2 - SCM, Software Configuation Management..................................................83.1.3 - Repository.....................................................................................................83.1.4 - Property e Filtraggio delle Risorse..............................................................103.1.5 - Profili...........................................................................................................11

3.2 - Gestione delle Versioni.......................................................................................123.2.1 - SVN, Subversion..........................................................................................13

3.3 - Continuous Integration.......................................................................................133.3.1 - Apache Continuum......................................................................................14

3.4 - FTP, Modalità di Rilascio.....................................................................................153.5 - Stesura dei Requisiti............................................................................................163.6 - Realizzazione modello Concettuale E-R..............................................................18

3.6.1 - Stesura dei Requisiti del Sistema Informativo............................................183.6.2 - Glossario dei Termini...................................................................................193.6.3 - Schema concettuale E-R..............................................................................20

4 - Realizzazione...............................................................................................................224.1 - Interazione tra Sistemi e Ruolo degli Attori........................................................224.2 - Diagrammi di sequenza.......................................................................................234.3 - Progettazione Logica e Fisica della base dati......................................................254.4 - Implementazione................................................................................................274.5 - Tecnologie e Framework utilizzati.......................................................................28

4.5.5 - Hibernate e Gestione della Persistenza......................................................294.6 - Definizione dei Servizi.........................................................................................30

4.6.1 - ScmService..................................................................................................304.6.2 - CisService....................................................................................................31

4.7 - Interfaccia...........................................................................................................324.7.1 - Installazione e Configurazione....................................................................324.7.2 - Esempio d'uso.............................................................................................34

4.8 - Configurazione delle Applicazioni da Gestire.....................................................365 - Conclusioni.................................................................................................................386 - Riferimenti..................................................................................................................39


1 - INTRODUZIONE

In questo lavoro di tesi si tratterà delle tematiche relative alla gestione dei rilasci di applicazioni web, basate sull'ambiente Java, da parte di una software house. In particolare si affronta la questione delle personalizzazioni, dette anche profili, che debbono essere realizzate sulle diverse applicazioni per venire incontro alle esigenze e alle specifiche configurazioni dei clienti.

Tali personalizzazioni, alle volte anche significative, diventano un problema per le software house che devono gestire i propri applicativi mantenendo al tempo stesso le personalizzazioni già effettuate per i clienti. Il rischio in cui si incorre in assenza di un adeguato sistema di tracciatura dei rilasci è di imbattersi in incongruenze, possibili bug e disagi per le nuove implementazioni. Inoltre, la difficoltà che si riscontra nella installazione di applicazioni fortemente personalizzabili, diviene tale da rendere impossibile una netta separazione tra gli sviluppatori e gli addetti al cosiddetto “deploy”, ovvero la procedura di messa in produzione, che necessiteranno inevitabilmente di aiuti.

Come scopo finale, si vorrebbe realizzare una applicazione che permetta di gestire da un lato la possibilità di definire un profilo di compilazione specifico per il dato cliente e dall'altro mantenere traccia di quanto viene rilasciato e in che contesto.

Attualmente, soluzioni software che permettano la gestione dei profili esistono solo all'interno di specifici ambienti di sviluppo, ovvero necessitano dell'adozione di standard tecnologici e di implementazioni forzate nella realizzazione delle applicazioni. Tale situazione implica che, la scelta di adottare una soluzione esistente, viene ad essere subordinata all'attuale contesto di sviluppo della software house.

Per realizzare questo lavoro si è dunque proceduto alla analisi della situazione attuale di una grossa azienda di produzione software, nello specifico INSIEL MERCATO (Insiel Mercato S.p.A. con unico socio, località Padriciano 99 - AREA Science Park - 34149 Trieste). L'azienda è impegnata nello sviluppo di applicazioni per la pubblica amministrazione e per la sanità, e fornisce i propri applicativi a diversi clienti per i quali è necessario effettuare delle differenziazioni anche notevoli. Il reparto tecnologico che si è preso in considerazione è quello delle applicazioni web basate su ambiente java JEE. Successivamente si è analizzato l'insieme di tecnologie utilizzate per gli sviluppi delle suddette applicazioni, e tra queste si è ricercato il contesto comune che permettesse la possibilità di realizzare delle personalizzazioni con una modalità facilmente adottabile da tutti gli applicativi attualmente in rilascio, con il minimo sforzo di adattamento. Il passo finale ha consistito nel realizzare una applicazione che si occupasse di tenere traccia di tali personalizzazioni.


In concomitanza con la redazione di tale tesi, l'azienda stava procedendo all'introduzione di Maven, strumento dichiarativo per la gestione dei progetti Java in termini di compilazione del codice, distribuzione, documentazione e collaborazione del team di sviluppo. L'uso di questo supporto è dunque diventato un vincolo di progetto.

2 - SOMMARIO

La seguente trattazione illustrerà l'analisi effettuata per la comprensione della tematica che si intende affrontare con successiva elaborazione dei dati risultanti.

• Raccolta delle informazioni sulla situazione corrente della azienda per conto della quale si sta operando;

• Identificazione di Maven come principale punto in comune tra i diversi prodotti realizzati dalla azienda, avente le possibilità di gestire in modo opportuno i profili;

• Studio di Maven e delle modalità con cui questo effettua il filtraggio delle risorse statiche e di come tale operazione venga influenzata dalla definizione di un profilo;

• Interazione con sistemi di subversion;• Studio dei concetti e delle possibilità offerte dai sistemi di Continuous

Integration;• Analisi del prodotto Apache Continuum e del suo utilizzo da remoto;• Studio della possibilità di realizzazione di plugin personalizzati per Maven;• Studio delle tecnologie necessarie alla realizzazione della interfaccia

dell'applicativo;• Studio del diagramma ER (Entità/Relazione) della base dati;

In un secondo tempo, verranno descritti i modi in cui tali considerazioni entrano in gioco per lo sviluppo concreto dell'applicativo nella sua parte di business logic.

• Modellazione dell'applicativo ed integrazione con sistemi esterni;• Definizione dei diversi moduli che compongono lo strato di Service;• Progettazione logica della base dati e implementazione di Hibernate;• Identificazione dei flussi applicativi, con particolare attenzione ai ruoli previsti

per gli utenti;• Modifiche richieste alle applicazioni che verranno interessate dal sistema di

rilascio.

Una breve sezione riguarderà l'implementazione dell'indispensabile interfaccia per l'interazione con l'utente.

• Sviluppo di una applicazione web per l'interazione tra utente e sistema;• Illustrazione delle modalità di installazione e configurazione della applicazione;

2 - Sommario Pag. 5/39

• Delucidazione sui casi d'uso più comuni per la applicazione.

Infine trovano posto le conclusioni tecniche-oggettive e personali raggiunte al termine dello sviluppo. Per le note informative che esulano da questa trattazione si è predisposta una appendice di approfondimento cui si fa svariate volte riferimento.

3 - ANALISI

Prima di procedere con la progettazione e la successiva realizzazione del progetto, occorre stabilire a priori quelli che sono i requisiti che si vuole vengano rispettati nello sviluppo. Per poter tracciare un ben definito elenco di requisiti è indispensabile effettuare una analisi approfondita della problematica che si vuole affrontare, dello stato dell'arte, delle tecnologie che sono disponibili al momento e delle possibili soluzioni che vengono offerte da queste.

Il punto centrale da cui inizia questa analisi è il tool di sviluppo Maven. Tale strumento è presente in tutti i progetti che si vuole gestire con il futuro applicativo e permette di controllare un gran numero di funzionalità.

In questa analisi si cercherà dunque di analizzare Maven, mettendo in risalto le modalità con cui questo tool riesce a interagire con gestione delle versioni, uso dei profili e modalità di rilascio.

3.1 - Maven

Maven, può essere considerato principalmente come uno strumento per la gestione di progetti software Java, in termini di compilazione del codice, testing, distribuzione, documentazione e collaborazione del team di sviluppo. Si tratta dunque di un tentativo di applicare pattern ben collaudati all'infrastruttura del build dei progetti cercando di coprirne tutti gli ambiti.

Si tratta di promuovere la comprensione e la produttività del team coinvolto nello sviluppo, fornendo un percorso chiaro all'utilizzo di best practice. Per questo motivo Maven è definito, sinteticamente, tool per la gestione e comprensione dei progetti. Esso è quindi contemporaneamente un insieme di standard, una struttura di repository e un'applicazione che servono alla gestione e alla descrizione di progetti software. Esso definisce un ciclo di vita standard per il building, il test e il deployment di file di distribuzione Java.

Le caratteristiche di Maven fanno sì che diverse persone, anche inizialmente estranee al progetto, possano lavorare insieme produttivamente senza dover trascorrere molto

3 - Analisi Pag. 6/39

tempo per comprendere la struttura del progetto, il suo funzionamento, il processo di build, etc. Tutti coloro che si sono trovati, almeno una volta nella loro vita, a dover intervenire in progetti di grandi dimensioni in corso d'opera, sicuramente conoscono la frustrazione causata da dover capire rapidamente l'interazione delle varie parti del progetto, l'ordine e le dipendenze del processo di build, etc.

Le aree prese in considerazione da Maven sono: build, documentazione, reportistica, gestione delle dipendenze, SCMs (Software Configuration Management), rilascio e distribuzioni di nuove versioni. In effetti tutti i progetti, indipendentemente dal loro dominio, dalla loro estensione e dalla tecnologia impiegata, presentano una serie di necessità standard, quali ad esempio:

• la conversione dei sorgenti in codici "eseguibili" (build);• la verifica (test);• l'assemblaggio;• la documentazione; • eventualmente il "dispiegamento" e la relativa configurazione (deployment).

3.1.1 - Struttura dei file Pom.xml

Uno dei principali componenti di Maven è il file pom.xml (Project Object Model, modello ad oggetti del progetto). Esso mantiene i meta-dati del progetto memorizzati utilizzando il formato xml.

Il file POM presenta una struttura piuttosto articolata e complessa. Tuttavia la maggior parte delle funzionalità vengono implementate di base con un comportamento di default che risulta essere perfettamente compatibile con la maggioranza dei progetti. Inoltre un file POM personalizzato per un dato progetto può essere facilmente riutilizzato per i successivi, con variazioni minime.

La complessità del POM che può inizialmente spaventare chi non è pratico dell'ambiente, offre al tempo stesso un punto di forza per chi volesse alterare il comportamento di Maven. Questa elevata versatilità sarà il punto di partenza per lo sviluppo di questo progetto.

Tralasciando la struttura generica del POM, che esula da questa trattazione, nei paragrafi successivi si affrontano con più attenzione, le parti che hanno una relazione con quanto si discute in questa analisi. Si vedranno dunque le modalità di filtraggio delle risorse, la definizione di property, la gestione dei profili e dei riferimenti a server SCM e di rilascio.


3.1.2 - SCM, Software Configuation Management

Il software per la gestione della configurazione, detto in inglese Software Configuation Management o più semplicemente con l'acronimo SCM, è il software dedicato alla gestione dei file sorgenti e risolvono il problema del Version Control.

Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM. Questo fornisce un'interfaccia comune per accedere alle diverse implementazioni SCM (CVS, Subversion, IBM ClearCase, etc.).

<project>... <scm> <connection>scm:svn:https://scmsever.com/myPrj/trunk/</connection> <developerConnection> scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/ </developerConnection> <tag>trunk</tag> <url>scm:svn:https://scmsever.com/myPrj/trunk/myPrj</url> </scm>...</project>

Gli elementi SCM (listato appena visto) sono:• connection e developerConnection permettono di definire le diverse modalità

di connessione al sistema di controllo del versionamento attraverso Maven. In particolare, mentre la connessione utilizzata da Maven (connection) richiede un accesso di sola lettura necessaria per permettere a Maven di localizzare e leggere il codice sorgente, la connessione degli sviluppatori (developerConnection), invece, richiede un accesso in lettura/scrittura. Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM. Questo fornisce un'interfaccia comune per accedere alle diverse implementazioni SCM (CVS, Subversion, IBM ClearCase, etc.). Questa interfaccia è basata su una API ispirata al seguente formato URL: scm:[provider]:[provider_specific]. Nel listato riporato sopra è presente una configurazione contenente una connessione protetta (HTTPS) al server Subversion.

• tag permette di specificare l'etichetta (la radice dell'SCM) dalla quale è possibile accedere al progetto.

• url, permette di specificare l'indirizzo URL che permette di navigare il repository

3.1.3 - Repository

Mentre le sezioni repository del POM permettono di specificare le posizioni e le modalità con cui Maven è in grado di effettuare il download dei vari manufatti necessari al POM, questa sezione, all'interno dell'elemento distributionManager,


permette di specificare dove e come memorizzare i manufatti del progetto, in fase di deployment, all'interno del repository. Qualora la sezione snaposhotRepository non sia definita, le impostazioni dell'elemento repository sono utilizzati anche per la distribuzione di tipo snapshot. Ecco il listato che illustra le sezioni snapshotRepository e Repository all'interno della sezione distributionManagement.

<project>... <distributionManagement> <repository> <uniqueVersion>false</uniqueVersion> <id>corp1</id> <name>Corporate Repository</name> <url>scp://repo1/maven2</url> <layout>default</layout> </repository> <snapshotRepository> <uniqueVersion>true</uniqueVersion> <id>propSnap</id> <name>Propellors Snapshots</name> <url>sftp://propellers.net/maven</url> <layout>legacy</layout> </snapshotRepository> ... </distributionManagement>...</project>

Gli elementi di queste sezioni sono:• id, name: entrambi i campi servono per identificare il repository. Mentre il

campo id è un identificatore univoco, il nome serve per rendere il campo leggibile.

• uniqueVersion: è un attributo di carattere booleano il cui valore true serve ad incaricare Maven del versionamento dei vari manufatti pubblicati (generazione di un numero di versione univoco da associare ai manufatti memorizzati nel repository). Il valore false invece indica che la versione è definita come parte dell'indirizzo.

• url: come lecito attendersi rappresenta l'informazione principale dell'elemento repository. Il formato URL, permette di specificare sia l'ubicazione sia il protocollo di trasporto da utilizzare per il trasferimento dei manufatti generati dal processo di build.

• layout: come visto in precedenza permette di specificare la struttura del repository. In particolare: default indicata la struttura introdotta con Maven 2, mentre legacy rappresenta la struttura precedente.


3.1.4 - Property e Filtraggio delle Risorse

Per filtraggio delle risorse si intende la sostituzione di variabili sui file di configurazione costituenti il nostro progetto.

Per far si che le risorse vengano filtrate occorre abilitare il filtering nel tag resources. Se il filtraggio delle risorse è attivo, prima di qualsiasi operazione di compilazione, il framework si preoccupa di controllare tutti i file di risorsa (di default si trovano nella cartella /src/main/resources) e di sostituirne le variabili con alcuni valori preimpostati. Tali valori possono essere definiti come properties del progetto generico oppure, come si vedrà in seguito, definiti a livello di profilo.

<project>... <properties> <jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname> <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url> <jdbc.username>dev_user</jdbc.username> <jdbc.password>s3cr3tw0rd</jdbc.password> </properties> ... <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>

Come esempio si consideri un file di properties, facente parte di un dato progetto, in cui vengono specificati i parametri di connessione verso la base dati. Tale file deve essere configurato in modo differente in base al contesto di compilazione (macchina locale dello sviluppatore, server di sviluppo, clienti). Il file che si troverà nei sorgenti del progetto, sarà dunque formattato come indicato di seguito:

driver=${jdbc.driverclassname}url=${jdbc.url}username=${jdbc.username}password=${jdbc.password}

Si può vedere che il file non è valorizzato ma, in fase di compilazione, verranno utilizzate le properties definite nel POM del progetto per sostituire i placeholder definiti da ${<chiave>}.


3.1.5 - Profili

Una caratteristica introdotta a partire dalla versione 4.0 dei POM sono i profili. Queste sezioni permettono di variare opportune impostazioni in funzione dell'ambiente di build. Ciascun profilo include sia una sezione opzionale dedicata all'attivazione (una sorta di trigger per un profilo) sia un insieme di variazioni da apportare al POM qualora il relativo profilo venga attivato. Un esempio classico consiste nel far in modo che un progetto realizzato per eseguire determinati test faccia riferimento ad un diverso database a seconda dell'ambiente di esecuzione. Un altro esempio consiste nel far sì che il sistema, a seconda della versione del JDK utilizzata, prelevi opportune impostazione da diversi repository.

<project>... <profiles> <profile> <id>test</id> <activation>...</activation> <build>...</build> <modules>...</modules> <repositories>...</repositories> <pluginRepositories>...</pluginRepositories> <dependencies>...</dependencies> <reporting>...</reporting> <dependencyManagement>...</dependencyManagement> <distributionManagement>...</distributionManagement> </profile> </profiles></project>

Gli elementi del profilo permettono di ridefinire elementi già presenti all'interno del POM, pertanto ne ricopiano la struttura, come si può vedere nel precedente listato.

E' possibile riunire le possibilità di filtering delle risorse e gestione dei profili ottenendo la possibilità di valorizzare differentemente determinate risorse statiche mediante l'uso dei profili. Il risultato è un listato simile al seguente.

<project>... <properties> <jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname> <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url> <jdbc.username>dev_user</jdbc.username> <jdbc.password>s3cr3tw0rd</jdbc.password> </properties> ... <build> <resources> <resource> <directory>src/main/resources</directory>


<filtering>true</filtering> </resource> </resources> </build> ... <profiles> <profile> <id>production</id> <properties> <jdbc.driverclassname> oracle.jdbc.driver.OracleDriver </jdbc.driverclassname> <jdbc.url>jdbc:oracle:thin:@proddb01:1521:PROD</jdbc.url> <jdbc.username>prod_user</jdbc.username> <jdbc.password>s00p3rs3cr3t</jdbc.password> </properties> </profile> </profiles></project>

3.2 - Gestione delle Versioni

Si definisce controllo delle versioni, la gestione di versioni multiple di un insieme di informazioni. Viene usato prevalentemente nello sviluppo di progetti informatici per gestire la continua evoluzione dei documenti digitali come il codice sorgente del software. Le modifiche a questi file sono identificate incrementando un numero o un codice associato ad essi, denominato "numero di versione", "etichetta di versione", o semplicemente "versione", e sono etichettate con il nome della persona che ha apportato la modifica.

Gli strumenti software per il controllo versione sono sempre più riconosciuti essere necessari per la maggior parte dei progetti di sviluppo software.

Nell'ingegneria del software, il controllo delle versioni è costituito da qualunque pratica che tenga traccia e permetta di controllare i cambiamenti al codice sorgente. Gli sviluppatori software talvolta usano il controllo versione software anche per i file di documentazione e di configurazione, oltre che per il codice sorgente. In teoria, il controllo versione può essere applicato a qualunque tipo di registrazione di informazioni.

Riassumendo, l'obiettivo fondamentale di tutti i software che si occupano del controllo di versione è permettere a diversi sviluppatori di lavorare contemporaneamente su diversi file o addirittura sullo stesso file, automatizzando compiti come:

• tenere traccia di chi sta modificando che cosa;• unire le modifiche una volta complete;• segnalare eventuali conflitti;• tenere una copia di ogni precedente versione e fare in modo che sia facilmente

recuperabile.


3. 2.1 - SVN, Subversion

Subversion (noto anche come SVN, che è il nome del suo client a riga di comando) è un sistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, oramai considerato superato.

Rispetto a CVS, Subversion introduce:• versionamento delle directories: con CVS il controllo di versione era applicato

solo ai file, quindi le operazioni di copia e spostamento tra diverse directory non era gestito adeguatamente. Con Subversion viene tenuta traccia anche del contenuto di ogni singola directory e quindi lo spostamento di un file è a tutti gli effetti considerata una modifica, quindi rintracciabile e reversibile.

• commits atomici: una serie di modifiche viene applicata solo in blocco – se anche solo una di esse crea errori, non viene applicata nessuna delle modifiche inviate. Questo evita la creazione di versioni incomplete che dovrebbero poi essere corrette a mano.

• versionamento dei metadati: è possibile assegnare a file e directory delle proprietà personalizzate – dei veri e propri metadati – e mantenere lo storico anche delle modifiche a queste proprietà.

• astrazione dal livello di rete: l'accesso dal client al repository (cioè al deposito centralizzato dei files) può avvenire attraverso il protocollo HTTP (sfruttando un apposito modulo di Apache), attraverso un apposito server standalone (SVNServe), o direttamente attraverso il filesystem (ma solo nel caso in cui il repository sia situato sulla stessa macchina). In tutti questi casi, i comandi e le operazioni fondamentali non cambiano, così come non cambia la struttura del repository e delle copie di lavoro locali.

3.3 - Continuous Integration

Con il termine Continuous Integration si intende una pratica di sviluppo software in cui i membri di un team devono integrare il proprio lavoro con la linea di sviluppo


principale. Con elevata frequenza si considera almeno una integrazione al giorno per ogni membro del team. Tali integrazioni vengono verificate da una compilazione automatica (che comprende anche l'esecuzione di test) per rilevare errori di integrazione il più rapidamente possibile. Molti team trovano che questo approccio porta a ridurre significativamente i problemi di integrazione e permette di sviluppare software più rapidamente.

I sistemi che eseguono la integrazione continua, come Cruise Control, Apache Continuum, TeamCity, e così via, sono ormai presenti in ogni progetto che si rispetti. Si tratta di sistemi che, su richiesta, o ad intervalli predefiniti (ogni ora, durante le ore notturne) eseguono il processo di build dell'intero progetto.

3.3.1 - Apache Continuum

Apache Continuum è uno dei principali applicativi open source per l'integrazione continua progettato per build java. Una caratteristica che lo distingue da altri strumenti similari è la gestione della sicurezza basata sui ruoli. Questa funzione fornisce il controllo su quali aspetti della compilazione possono essere visti e gestiti dai diversi utenti. Nel complesso, le caratteristiche principali sono simili a quelle appartenenti ad altri applicativi di build management come Hudson e Cruise Control (gestione dei rilasci, notifica e-mail, integrazione con i più diffusi strumenti di compilazione, integrazione con Maven e integrazione con sistemi di SCM come SVN o CVS).

Lo strumento di interfaccia utente è web based, e dopo che il server è stato avviato si può accedere da browser con un collegamento a http://localhost:8080/continuum.

Apache Continuum offre inoltre la possibilità di accedere alle proprie funzionalità anche da remoto mediante un client XML-RPC. Il client è accessibile mediante un collegamento a http://localhost:8080/continuum/xmlrpc.


3. 4 - FTP, Modalità di Rilascio

Il File Transfer Protocol (protocollo di trasferimento file o FTP), è un Protocollo per la trasmissione di dati tra host basato su TCP. Gli obiettivi principali di FTP descritti nella sua RFC ufficiale sono:

• Promuovere la condivisione di file (programmi o dati);• Incoraggiare l'uso indiretto o implicito di computer remoti; • Risolvere in maniera trasparente incompatibilità tra differenti sistemi di

stoccaggio file tra host;• Trasferire dati in maniera affidabile ed efficiente.

E' stato necessario interessarsi al protocollo FTP perché questo metodo di distribuzione viene utilizzato per effettuare i rilasci in Insiel Mercato così come in moltissime altre aziende ed è una delle principali modalità con cui vengono effettuati i trasferimenti di file di grosse dimensioni.

Per permettere a Maven di interagire con un repository FTP, è necessario utilizzare una particolare estensione del plugin wagon (utilizzato per prelevare e memorizzare file in server remoti).

<project> ... <build> ... <extensions> <extension> <groupId>org.apache.Maven.wagon</groupId>


<artifactId>wagon-ftp</artifactId> <version>1.0-alpha-3</version> </extension> </extensions> ... </build> ...</project>

3.5 - Stesura dei Requisiti

Nei paragrafi precedenti, si sono esaminate le tecnologie comuni alle applicazioni attualmente sviluppate dalla azienda Insiel Mercato, e su queste si sono esaminate le caratteristiche che sembrano poter offrire la soluzione al problema della gestione di profili e versioni.

Il risultato dell'analisi si riassume nelle seguenti note:• Il tool Maven offre la possibilità di gestire dei profili in modo tale che, in fase di

compilazione del progetto, gli attributi che vengono definiti nel file POM dei progetti, siano sovrascrivibili o comunque modificabili.

• Un particolare punto di interesse nella nota precedente è costituito dalle properties, associazioni tra chiavi e valori configurabili da profilo, che possono essere utilizzate come placeholder all'interno delle risorse statiche dei progetti;

• I profili maven, così come le properties, possono trovarsi anche esternamente al POM, ed essere iniettati durante la fase di compilazione.

• Ad ogni versione di un progetto Maven, corrisponde un tag su SVN. Considerando che un tag non rappresenta una linea di sviluppo ma un punto (è dunque non è modificabile), non si può pensare di modificare i sorgenti del progetto per poter integrare il profilo all'interno del pom del progetto stesso.

• Sulla base della nota precedente, si comprende come sia necessario che i profili vengano definiti all'interno di un sistema che sia indipendente dal gestore del versionamento. Tale sistema dovrà essere in grado, non solo di memorizzare i profili, ma anche di crearli e di poterli associare ai clienti.

• Si riscontra che sia possibile utilizzare un sistema di Continuous Integration per eseguire delle operazioni Maven, che questi abbiano delle interfacce remote, e che Maven consenta di effettuare il deploy di un compilato su di un server FTP.

Le note sopra esposte definiscono non solo il risultato della analisi ma anche il documento dei requisiti che l'applicativo che si vuole realizzare dovrà essere in grado di soddisfare. In particolare, sulla base di quanto appena illustrato si vuole realizzare una applicazione che sia in grado di:

• creare dei profili di compilazione per progetti Maven in base alle configurazioni dei clienti;

• memorizzare i suddetti profili, e le relazioni con progetti e clienti, in un archivio locale;

• utilizzando i profili creati, far eseguire ad un motore di Continuous Integration il


rilascio dell'applicazione per il dato cliente su di un server FTP.

Dalla rielaborazione delle note e delle considerazioni appena esposte, si possono enunciare i seguenti requisiti di progetto.

• L'applicazione dovrà essere in grado di distinguere la figura dello sviluppatore da quella dell'addetto alla messa in produzione e per ciascuno di essi fornire le funzionalità strettamente necessarie all'esercizio delle proprie funzioni. In tal modo si riusciranno ad isolare le responsabilità e meglio definire gli standard di esecuzione.

• Deve essere possibile, all'interno della applicazione, gestire le connessioni verso i build manager o continuous integration system, verificandone la corretta raggiungibilità e permettendo l'importazione di progetti da essi.

• Devono essere registrabili e modificabili le definizioni dei clienti.• Deve essere possibile importare progetti dal sistema di integrazione continua e

registrarli all'interno dell'applicativo oppure, viceversa, da questo, dopo aver inserito i parametri fondamentali, effettuare un export verso in sistema esterno.

• L'applicativo deve possedere, per ogni progetto, i riferimenti al posizionamento su di un sistema SCM.

• Dai riferimenti SCM di ogni progetto deve essere possibile effettuare il checkout dei sorgenti e da questi ricavare un template di definizione dei profili, caratteristico del progetto che si sta profilando.

• Sulla base dei template dei profili ed in associazione con progetto e cliente, deve essere possibile per l'utente, inserire i parametri che caratterizzano il profilo e salvare quest'ultimo nella base dati.

• L'applicazione deve poter far eseguire, ad un sistema di Continuous Integration remoto, un comando maven di compilazione di un progetto, in base al profilo voluto.

• Il risultato del comando di build indicato precedentemente deve avere come esito positivo, il deploy del compilato del progetto su di un server FTP. Tale compilato deve contenere la configurazione definita nel profilo.

• In seguito al deploy eseguito con successo, deve essere registrata l'esecuzione del rilascio per il dato cliente.

• Con una ulteriore interrogazione del sistema SCM, si preleva un secondo template che specifica le informazioni importanti che occorre registrare per il dato progetto.

• Sulla base del template sopra esposto, deve essere possibile registrare le informazioni ottenute dal cliente sull'ambiente specifico di installazione.

• L'applicativo deve permettere ricerche esaustive sulla base di progetti, versioni e clienti.


3.6 - Realizzazione modello Concettuale E-R

Essendo necessario l'utilizzo di una base dati per immagazzinare le informazioni relative a progetti, clienti, profili e rilasci, si rende indispensabile effettuare una corretta progettazione della stessa. Un errore durante questa fase si ripercuoterebbe sull'intero progetto, mentre una base di dati ben progettata risulterebbe invece più efficiente e semplificherebbe lo sviluppo delle applicazione.

Il procedimento per la progettazione di una base di dati segue i seguenti passi:• Stesura dei requisiti del sistema informativo in linguaggio naturale;• Glossario ed identificazione delle entità;• Realizzazione del Modello ER.

Nel capitolo relativo alla realizzazione, vengono effettuati ulteriori elaborazioni dello schema E-R fino a giungere allo schema logico e fisico.

3.6.1 - Stesura dei Requisiti del Sistema Informativo

Si produce una prima versione dei requisiti in linguaggio naturale, raggruppando frasi descrittive relative a categorie diverse di dati.

Frasi riguardanti i progetti:• Un Continuous Integration System viene utilizzato per il testing dei progetti.• I progetti vengono compilati da un Continuous Integration System.• I progetti sono versionati su un gestore di versioni SCM.• Gli sviluppatori depositano i progetti su SCM e Continuous Integration System.

Frasi relative ai Profili:• Il profilo è la definizione della personalizzazione di un progetto.• Ogni cliente può volere uno o più profili dello stesso progetto.• Ogni compilazione viene eseguita con un certo profilo.• Il template del profilo viene preso dai sorgenti versionati del progetto.• I deployer sono incaricati della realizzazione dei profili.

Frasi relative al build:• Il build viene fatto dal Continuous Integration System.• Tutti i progetti sono gestiti dal Continuous Integration System.• Il Continuous Integration System riceve i profili dall'applicazione rudra.• Un build riuscito può essere rilasciato al cliente.• I deployer installano i progetti dai clienti.

Frasi relative al cliente:• Il cliente richiede il rilascio di un progetto;


• Il progetto rilasciato viene configurato per il cliente.• Al cliente viene installato il prodotto richiesto.

Frasi relative ai rilasci:• Se un build da esito positivo può essere installato.• Ad ogni installazione corrisponde un buildn di un progetto.• Le installazioni vengono fatte dai deployer.

Frasi relative agli sviluppatori:• Ogni progetto ha uno o più sviluppatori.• Gli sviluppatori utilizzano il server SCM per versionare i progetti.• Gli sviluppatori monitorano i progetti con i CIS.

Frasi relative ai deployer:• I deployer creano i profili per i progetti.• Una installazione corrisponde all'intervento di un deployer su un progetto.

3.6.2 - Glossario dei Termini

Analizzando le frasi espresse in linguaggio naturale, raggruppate per categoria di dati, si possono identificare dei termini ricorrenti e tra questi delle relazioni.

Termine Descrizione Collegamenti

Progetto Prodotto venduto dalla azienda Sviluppatore, Profilo, CIS, SCM, Build

Profilo Personalizzazione del progetto per il cliente Deployer, Progetto, Cliente, Build

Cliente Colui a cui si vende il progetto personalizzato Installazione, Profilo

Sviluppatore Sviluppa i Progetti Progetto

Deployer Crea i profili e installa i progetti compilati Profilo, Installazione

Build Rappresenta il processo con cui si crea il compilato e i suoi risultati

Progetto, Profilo, Installazione

CIS Continuous Integration Systema Progetto

Installazione Installazione del progetto compilato presso il cliente

Deployer, Cliente, Build

SCM Sistema di versionamento Progetto


3.6.3 - Schema concettuale E-R

Traducendo il glossario in uno schema concettuale basato su Entità e Relazioni si ottiene lo schema indicato di seguito. Questo è lo schema scheletro dal quale si parte con l'analisi che condurrà alla realizzazione dello schema E-R vero e proprio.

Dallo schema precedente si può immediatamente evincere che le entità Sviluppatore e Deployer possono essere considerate delle specializzazioni della figura del Dipendente. Inoltre dalla comprensione delle frasi in linguaggio naturale e dalla analisi del contesto costituito dal sistema informativo che si vuole realizzare, è possibile definire sia gli attributi che le singole entità (e nel caso, anche le relazioni) debbano avere, sia la cardinalità con cui le entità entrano in relazione tra loro. Questa analisi è di fondamentale importanza per lo sviluppo dello schema logico e fisico che si andrà a svolgere nel capitolo relativo alla realizzazione della base dati.


Di seguito viene quindi esposto lo schema Entità-Relazione su cui si è strutturata la base dati del progetto Rudra.

4 - Realizzazione Pag. 21/39

4 - REALIZZAZIONE

In considerazione del fatto che l'applicativo in realizzazione necessiterà di essere utilizzato da diverse figure professionali (sviluppatori, addetti alla messa in produzione, project manager, ecc..) e in diversi contesti (tutti però localizzabili all'interno dell'azienda), si è deciso di realizzare una applicazione web. Tale scelta permette una maggiore semplicità d'uso ed è ottimizzata per l'uso intranet. Essa viene inoltre giustificata dagli stretti legami con altri applicativi ad uso intranet come sistemi di continuous integration, repository per il controllo delle versioni, repository maven interni, server ftp per i rilasci, server ldap per le autenticazioni e sistemi di issue tracking.

4.1 - Interazione tra Sistemi e Ruolo degli Attori

Si vuole realizzare una applicazione capace di gestire un elenco di progetti posti in un sistema di Continuous Integration. Di tali progetti deve essere possibile ricavare i riferimenti al server di versionamento SCM da cui a sua volta si estraggono le informazioni necessarie alla compilazione di un profilo. Successivamente, in base alle informazioni appena fornite dal sistema SCM, si procede alla creazione di un nuovo profilo per il dato cliente associandolo al progetto stesso all'interno del database dell'applicazione Rudra. Tale profilo viene poi utilizzato per la generazione del progetto personalizzato da parte del sistema di continuous integration che provvederà al deploy del compilato finale su di un server FTP per la distribuzione. Inoltre si vuole registrare l'operazione di rilascio, arricchendola di informazioni specifiche del progetto e del cliente, all'interno del database.

In tutto questo processo, gli utenti che compiono le diverse attività possono essere categorizzati in due attori principali, ovvero:

• Sviluppatore: Colui che sviluppa e mantiene i progetti. Stabilisce i rilasci delle versioni e in concomitanza con questi eventi si occupa di realizza i tag sul sistema di versionamento e porre l'applicazione appena versionata su un sistema di continuous integration.

• Deployer: Colui che si occupa della messa in produzione degli applicativi. Non ha competenze riguardo al funzionamento dei progetti o delle tecnologie con cui questi sono stati realizzati. Si occupa di ricavare dai clienti le informazioni sul contesto in cui le applicazioni si troveranno ad operare, a configurarle adeguatamente realizzando un profilo, e a porre in produzione il compilato che potrà ricavare dal server FTP.


Come si può facilmente vedere dallo schema precedente, grazie all'introduzione di questo meccanismo di rilascio, non esistono punti in comune tra la figura dello sviluppatore e quella del deployer.

4.2 - Diagrammi di sequenza

I due attori principali che interagiranno con il progetto Rudra saranno dunque i deployer e gli sviluppatori. Per ciascuno di essi sono stati realizzati i seguenti diagrammi di sequenza.

Per la figura dello sviluppatore si hanno le seguenti operazioni:

• registrazione di un sistema di Continuous Integration;• richiesta del progetti importabili dal CIS;• importazione di un progetto.


Per la figura del deployer si hanno le seguenti operazioni:

• richiesta form per creazione del profilo;• salvataggio profilo;• richiesta rilascio;• salvataggio dettaglio rilascio.


4.3 - Progettazione Logica e Fisica della base dati

Non esistono DBMS in grado di operare direttamente sui concetti di schemi E-R. Risulta quindi necessario tradurli in altri schemi di dati chiamati logico relazionali. Questa traduzione può essere eseguita in modo semi-automatico seguendo una determinata serie di operazioni da eseguire.

Il progetto logico presenta in generale una soluzione standard determinabile in modo semplice e diretto. A seconda dei casi, sono però disponibili anche soluzioni alternative, che possono rivelarsi più o meno convenienti. In queste occasioni si deve tenere conto dell’efficienza dello schema logico risultante e delle operazioni da effettuare (derivanti da flussi e processi).


Per ottenere lo schema logico della base dati è necessario dunque procedere a trasformazioni e traduzioni dello schema E-R seguendo le fasi indicate di seguito:

• Eliminazione delle generalizzazioni;• Identificazione delle chiavi primarie;• Traduzione di entità e associazioni in schemi di relazioni.

Durante la realizzazione di queste fasi, si devono compiere le seguenti valutazioni, che permettono una ottimizzazione dello schema logico risultante dalla interpretazione dello schema E-R:

• Previsioni sulla natura e la frequenza delle operazioni;• Valutazioni quantitative sui volumi di dati (entità, associazioni, percentuali di

copertura di gerarchie, percentuali di valori nulli).

In tutti quei casi in cui sono possibili scelte alternative, occorre prestare la dovuta attenzione alle seguenti considerazioni, molto spesso intuitive:

• Le proprietà logiche sono comunque primarie rispetto ai motivi di efficienza;• Tenere sulla stessa entità informazioni che verranno di frequente consultate

insieme;• Tenere su entità separate informazioni che verranno consultate separatamente;• Limitare l’incidenza di valori nulli per attributi opzionali.

L'applicazione delle regole e delle considerazioni precedenti, porta alla stesura delle seguenti trasformazioni da applicare allo schema E-R:

• la relazione esistente tra CIS e Progetto ha cardinalità 1,1 sulla seconda entità, e su questa viene accorpata;

• vista la cardinalità 1,1 della relazione tra SCM e Progetto, la prima entità viene completamente accorpata nella seconda (questa soluzione facilita anche la gestione dei progetti e della interfaccia.);

• gli argomenti del Profilo, essendo molteplici, vengono estratti dall'entità Profilo e posizionati in una tabella a parte di cui il profilo è chiave esterna (tabella Profile_Property);

• le dipendenze aggiuntive che possono essere richieste da un Profilo possono essere molteplici, quindi vengono estratte dall'entità Profilo e posizionate in una tabella a parte di cui l'identificativo del profilo è chiave esterna (tabella Profile_Dependency);

• gli argomenti della Installazione, essendo molteplici, vengono estratti dall'entità Installazione e posizionati in una tabella a parte di cui l'identificativo del profilo è chiave esterna (tabella Release_Property);

• in tutti i casi in cui la cardinalità con cui una entità entra in relazione è 1,1, la relazione viene accorpata alla entità stessa;

• l'identificazione delle chiavi primarie segue le indicazioni già fornite nello schema E-R realizzato.

All'interno degli applicativi sviluppati da Insiel Mercato, la gestione di autenticazioni ed autorizzazioni degli utenti, viene svolta da un kernel di funzionalità, condiviso tra tutte le applicazioni, che utilizza una base dati condivisa. Trattandosi dunque di una


soluzione già esistente e proprietaria, essa non viene trattata in questo studio.

Il risultato di tutte queste considerazioni, applicate sullo schema entità-Relazione che è stato elaborato nella fase di Progettazione di questa tesi, ha prodotto lo schema logico che ha come prodotto il seguente schema fisico.

4.4 - Implementazione

L'applicazione web che si intende sviluppare presenterà tre diversi strati software.

Il primo, ovvero lo stato dei controller sarà recettivo delle richieste http inviate dal browser dell'utente. Si occuperà dunque di verificare autenticazioni ed autorizzazioni e di fornire successivamente una risposta in base a ciò che verrà restituito dai servizi che verranno di volta in volta richiamati.

Il secondo strato è uno strato di servizi che rispettano il pattern meglio noto come Facade. Tali servizi permettono di nascondere la complessità delle operazioni ai controller o agli altri servizi chiamanti. In tal modo la complessità di certe operazioni complesse viene ad essere concentrato in un punto, ed essendo i servizi realizzati nel modo più generico e astratto possibile, il codice sviluppato è estremamente riusabile.


Il terzo strato è quello dedicato alla persistenza. Tale livello non è sempre presente. Grazie all'utilizzo di un motore di persistenza come Hibernate, non sarebbe necessario realizzare uno strato che si occupi delle operazioni di scrittura e lettura sulla base dati, ma in quei casi in cui le operazioni di lettura e scrittura possono essere più complesse e magari ricorrenti all'interno dei diversi servizi, allora si preferisce estrarre il codice relativo e posizionarlo in una classe di appoggio.

L'interazione con i servizi di versionamento SCM e di Continuous Integration CIS sono gestiti da appositi servizi.

4.5 - Tecnologie e Framework utilizzati

Per la realizzazione dell'applicazione web si è scelto di utilizzare il framework Spring. Spring è un framework open source per lo sviluppo di applicazioni che rappresenta al momento il tentativo più riuscito per semplificare lo sviluppo di applicazioni "enterprise" di una certa complessità nell'ambito Java. Spring interpreta nel modo migliore i nuovi modelli di programmazione definiti dall'IoC e dall'AOP e permette di raggiungere un livello di disaccoppiamento degli strati applicativi impedito invece dalla natura "invasiva" della tecnologia EJB.

Si prestano molto bene alla realizzazione del progetto anche alcuni sotto-framework di spring, quali Spring MVC (per la miglior gestione del pattern Model-View-Control) e Spring Security (per la gestione di autenticazioni e autorizzazioni).

Le view che vengono restituite agli utenti sono generate grazie alle JSP la cui composizione viene realizzata dal framework Tiles 2. Tiles permette agli sviluppatori di


definire frammenti di pagine jsp che possono essere assemblate in una pagina completa in fase di esecuzione. Questi frammenti possono essere utilizzati come semplice include, al fine di ridurre la duplicazione degli elementi di pagina comuni o incorporato in altri frammenti al fine di sviluppare una serie di modelli riutilizzabili.

4.5.5 - Hibernate e Gestione della Persistenza

Hibernate (talvolta abbreviato in H8) è una piattaforma middleware open source per lo sviluppo di applicazioni Java che fornisce un servizio di Object-relational mapping (ORM), ovvero che gestisce la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti Java.

L'obiettivo di Hibernate è quello di esonerare lo sviluppatore dall'intero lavoro relativo alla persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore, sia se si parte da zero sia se da un database già esistente. Hibernate genera le chiamate SQL e solleva lo sviluppatore dal lavoro di recupero manuale dei dati e dalla loro conversione, mantenendo l'applicazione portabile in tutti i database SQL. Hibernate fornisce una persistenza trasparente per "Plain Old Java Object".

In questa tesi sono state utilizzate le annotazioni JAXB per personalizzare la mappatura tra oggetti java, i cosiddetti POJO, e tabelle e altri costrutti SQL. Di seguito si riporta un esempio di classe di modello mappata con hibernate.

...@SuppressWarnings("serial")@Entity@Table(name = "project", uniqueConstraints = { @UniqueConstraint(columnNames={"group_id","artifact_id","version"})})public class Project implements Serializable {

@Id@GeneratedValue(strategy = GenerationType.IDENTITY)protected Long id;@Column(name = "group_id", nullable = false)protected String groupId;@Column(name = "artifact_id", nullable = false)protected String artifactId;@Column(name = "version", nullable = false)protected String version;@Column(name = "scm_url", nullable = false)protected String scmUrl;@Column(name = "scm_username", nullable = false)protected String scmUsername;@Column(name = "scm_password", nullable = false)


protected String scmPassword;@ManyToOne(cascade = CascadeType.ALL)protected ContinuousIntegrationSystem cis;@Column(name = "cis_project_id")protected Long cisProjectId;@Column(name = "invalidate", nullable = false)protected Boolean invalidate = false;

...// getter e setter per gli attributi della classe

L'annotazione @Entity permette ad Hibernate di riconoscere la classe come referenziata su di una tabella, l'annotazione @Id ne riconosce la chiave primaria e l'annotazione @ManyToOne permette di definire una chiave esterna con un'altra entità.

4.6 - Definizione dei Servizi

Come già detto,

4.6.1 - ScmService

Per interagire con il sistema di versionamento è necessario l'utilizzo di librerie esterne. Dopo una ricerca a riguardo si è scelto, per la particolare implementazione del servizio verso un sistema SVN, di utilizzare il progetto SVNKit. Tale libreria, tra l'altro, è anche utilizzata dallo stesso IDE Eclipse utilizzato per la realizzazione del progetto.

Per importare la libreria nel progetto occorre definire nel POM la seguente dipendenza

...<dependency> <groupId>org.tmatesoft.svnkit</groupId> <artifactId>svnkit</artifactId> <version>1.3.5</version></dependency>...

Per poter effettuare delle operazioni sul server SVN occorre conoscerne i riferimenti. Si riporta un esempio della connessione vai codice effettuata nel servizio.

...DAVRepositoryFactory.setup();

SVNUpdateClient client = new SVNUpdateClient( SVNWCUtil.createDefaultAuthenticationManager(


project.getScmUsername(), project.getScmPassword()), SVNWCUtil.createDefaultOptions(true));

client.doCheckout(SVNURL.parseURIDecoded(scmUrl), outputFolder, SVNRevision.UNDEFINED, SVNRevision.HEAD, SVNDepth.INFINITY, true);...

4.6.2 - CisService

Per connettersi remotamente ad una istanza di Continuum, occorre utilizzare il jar continuum-xmlrpc-client. Tale libreria può essere aggiunta come dipendenza al file pom del progetto.

... <dependency> <groupId>org.apache.continuum</groupId> <artifactId>continuum-xmlrpc-client</artifactId> <version>1.4.0</version> </dependency>...

Per connettersi a Continuum con il client xml-rpc indicato è necessario utilizzare la classe ContinuumXmlRpcClient, ilcui costruttore ha 3 parametri:

• url, l'url a cui risponde il listener xmlrpc (http://host:port/continuum/xmlrpc); • user, l'username dell'utente di Continuum;• password, la password dell'utente.

Per ottenere l'istanza del client nel codice java:

...URL url = new URL( "http://localhost:8080/continuum/xmlrpc" );ContinuumXmlRpcClient client = new ContinuumXmlRpcClient( url, username, password );...

Per ottenere la lista dei progetti:

...List<ProjectSummary> ps = client.getProjects( projectGroupId );...

Per richiamare il build di un progetto:

...client.buildProject( project.getId(), buildDefinitionId );...


4.7 - Interfaccia

L'interfaccia dell'applicativo è stata realizzata per permettere una facile interazione con l'utente. I contesti in cui si possono eseguire le operazioni sono rappresentati come dei Tab nella parte alta dell'interfaccia. Per ognuno di essi è presente un sotto menu che permette l'esecuzione delle varie operazioni. Un barra di navigazione permette di tenere traccia della posizione in cui ci si trova durante la navigazione della applicazione.

4.7.1 - Installazione e Configurazione

L'installazione dell'applicativo Rudra è piuttosto semplice. La sola cosa da fare è creare uno schema di database vuoto (in questa tesi si è utilizzata una base dati postgres, ma con pochissimi accorgimenti si può utilizzareq ualsiasi altro RDMS di uso comune) e indicarne i riferimenti nel file:

rudra\WEB-INF\application-config\persistence-config.xml

...<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="org.postgresql.Driver" /> <property name="url" value="jdbc:postgresql:rudra" /> <property name="username" value="rudra" /> <property name="password" value="rudra" /> </bean>...

Una volta mandato in esecuzione l'application server (in questo caso si è utilizzato Tomcat), hibernate si occuperà di realizzare lo schema della base dati sulla base degli oggetti di modello che sonos tati mappati con le annotazioni JAXB.

Per poter configurare l'applicazione in modo corretto, l'amministratore o uno degli sviluppatori deve accedere alla applicazione effettuando il login.


La prima operazione che deve essere eseguita è l'associazione di un sistema di Continuous Integration. In questa schermata devono essere inseriti i parametri relativi alla connessione remota.

Una volta associato il CIS, occorre importare i progetti da voler rilasciare. Questi vengono selezionati da una lista di tutti i progetti attualmente disponibili sul sistema CIS precedente mente associato.

La pressione del tasto importa, permette di registrare i progetti sulla base dati e di gestirli dal progetto Rudra.


4.7.2 - Esempio d'uso

Le seguenti schermate indicano le operazioni che normalmente vengono eseguite dal gruppo degli addetti ai rilasci. Una volta eseguito il login, essi verificano l'esistenza del cliente oppure, in caso contrario, lo inseriscono.

Si procede dunque alla generazione del profilo richiesto indicando esplicitamente il progetto che si vuole rilasciare e il relativo cliente.

Una volta che viene eseguita la registrazione del profilo, si procede con il checkout del progetto dal repository SCM su cui esse viene versionato, e se ne estrae il template di definizione dei placeholder.


Il template ottenuto contiene le indicazioni relative ai nomi delle chiavi dei placeholder e la descrizione di che cosa indicano. Tali template e tali note descrittive note sono state preventivamente indicati dagli sviluppatori prima di effettuare il tag del progetto.

Il deployer si occupa dunque di compilare il form per l'immissione dei dati del profilo aiutato in questa operazione dalla descrizione. Successivamente vedrà l'elenco dei profili, indicato di seguito, dal quale potrà richiedere la compilazioen remota e il deploy sul server di rilascio FTP.

Nell'arco di pochi secondi o pochi minuti a seconda della dimensione dle progetto e delle performance della rete intranet, sarà possibile interrogare il server FTP sul quale si troverà il file compilato richiesto.


4.8 - Configurazione delle Applicazioni da Gestire

Affinché un progetto gestito tramite Maven possa usufruire del sistema descritto in questa tesi, esso deve necessariamente:

• avere i propri file sorgenti versionati su di un sistema SCM raggiungibile;• i file sorgenti sopra indicati debbono essere sottoposti ad un sistema di

Continuous Integration raggiungibile;• avere nella root dei sorgenti, la definizione dei template che permettono la

definizione dei Profili e dei Rilasci;

Per poter utilizzare la generazione dei profili in Rudra, è necessario che i progetti da gestire abbiano al loro interno un file di definizione dei placeholder da sostituire in fase di compilazione. Il file viene posto nella root del progetto a pari livello del pom.xml e si chiama:

/rudra-profile-template.properties

In questo file sono presenti le coppie di chiave/descrizione, come illustrato nell'esempio:


rudra.db.driver=Se si utilizza un database Oracle, utilizzare il \ driver Oracle Thin JDBC: "oracle.jdbc.driver.OracleDriver". \rudra.db.url=Contiene il nome della sorgente di dati nella forma \ "jdbc:oracle:thin:@<server_name>:<db_port>:<SID>". Il valore \ server_name è l'indirizzo IP o il nome assegnato dall'admin \ del sistema al server di database. Il valore SID è l'identificatore\ del sistema di database. Se sullo stesso sistema sono in esecuzione\ più database Oracle, usare SID per distinguerli. Ad esempio, se il \ server si chiama Aristotle, la porta del database è la 1343 e su \ tale server è stato definito un SID di database di nome patients, \ immettere il seguente valore: \ "jdbc:oracle:thin:@Aristotle:1343:patients".rudra.db.username=Nome utente per l'accesso alla base dati.rudra.db.password=Password dell'utente.

Nel file pom devono essere presenti le seguenti sezioni. Tali modifiche vengono eseguite per poter utilizzare le modalità di deploy effettuate tramite il plugin wagon.

Definizione del repository per il deploy:

<distributionManagement> <repository> <id>ftp-repository</id> <url>ftp://192.168.1.104/home/ftp-user</url> </repository></distributionManagement>

Estensione del plugin Wagon: <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ftp</artifactId> <version>1.0-beta-6</version> </extension></extensions>

NB: Nello sviluppo di questo progetto si è deciso di utilizzare il plugin wagon di Maven per il deploy degli artefatti compilati sul server FTP, mediante l'estensione del plugin. Tale soluzione è efficace e stabile, in quanto wagon è un plugin intrinseco di Maven.

Si consideri però che l'utilizzo un plugin così specifico, può causare dei fastidi nel momento in cui si volessero effettuare delle modifiche alle modalità di deploy. Basti pensi al caso in cui si volesse far deployare il file compilato in una determinata cartella con allegati altri documenti, come guida all'installazione, o file connessi che comunque non riguardano il build in se stesso.

In tal caso la soluzione che si consiglia di adottare è di realizzare un plugin personalizzato di Maven da far in seguito inglobare in tutti i POM dei progetti gestiti tramite Rudra.


5 - CONCLUSIONI

L'obiettivo di questo lavoro di tesi era la realizzazione di una sistema software che permettesse di tenere traccia dei rilasci degli applicativi java web prodotti da una azienda di sviluppo software, con particolare attenzione alla gestione dei profili. Tale obiettivo si può dire pienamente raggiunto. Inoltre, grazie al fatto che i progetti della azienda erano gestiti con il tool Maven, si è potuto, non solo tenere traccia dei profili dei vari clienti, ma anche crearli direttamente nell'applicativo, grazie a dei template predefiniti. La successiva interazione con un sistema di Continuous Integration ha poi permesso che la generazione dei compilati da rilasciare avvenisse in modo assolutamente automatico e trasparente per il personale incaricato della messa in produzione.

Il progetto realizzato vanta una quasi immediata integrazione all'interno di un sistema preesistente, se dotato di gestione delle versioni (Subversion) e testing mediante meccanismi di continuous integration (Apache Continuum). Ciò significa che è possibile adottarlo senza incorrere nella necessità di dover riscrivere parti di applicazioni preesistenti o di dover modificare ambienti di lavoro. Il suo sviluppo ha richiesto notevole studio delle tecnologie disponibili e una buona conoscenza degli ambienti e delle meccaniche aziendali. La realizzazione vera e propria del progetto ha comportato alcuni mesi. Grazie al fatto che il codice è stato strutturato a moduli tra loro indipendenti, e che questi sono stati resi il più generici possibile, una buona parte del codice sviluppato nella parte di “business intelligence” può essere facilmente riutilizzato per altre applicazioni che ne debbano aver bisogno.

Personalmente, ritengo che tale progetto si possa definire di grande utilità per le aziende di produzione software, sia per quanto riguarda l'organizzazione e la reperibilità dei dati relativi a clienti ed installazioni, sia in termini di tempi e costi dovuti ad installazione, sviluppo e manutenzione dei prodotti. Nel caso specifico, ritengo che l'adozione di questo applicativo all'interno di Insiel Mercato, permetterà grandi evoluzioni nella fase di “deploy” dei prodotti, evitando i vari disagi in cui spesso capita di incorrere. Consentirà inoltre di aumentare velocità ed efficacia della manutenzione e di nuovi sviluppi, avendo sottomano una chiara mappatura della situazione della distribuzione dei progetti tra i clienti.

Il progetto realizzato verrà ulteriormente sviluppato nel corso dei prossimi mesi ed è prevista la sua entrata in produzione presso il laboratorio tecnico di sviluppo per la pubblica amministrazione di Insiel Mercato, nel mese di settembre. Prima del suo uso effettivo, se ne vogliono aumentare le caratteristiche, integrandovi il sistema di gestione di autenticazioni e autorizzazioni presente nell'azienda, fornendo l'interazione con JIRA (un sistema di issue tracking, ovvero un software che ha il compito di raccogliere e mantenere organizzate tutte le informazioni e le segnalazioni relative a gestione, sviluppo e programmazione di una applicazione), un servizio di invio notifiche

5 - Conclusioni Pag. 38/39

tramite posta digitale e personalizzare maggiormente quello che è al momento il comportamento dell'applicativo nella fase di deploy del compilato sul server ftp.

A completamento di questo lavoro di tesi vengono considerati i sorgenti del software realizzato, nonché i documenti specifici della applicazione, consistenti nella guida di installazione e configurazione.

6 - RIFERIMENTI

[1] Maven, http://maven.apache.org/ [2] Luca Vetti Tagliati, Mokabyte "Maven: best practice applicate al processo di build e rilascio di progetti Java. "

[3] Apache Continuum, http://continuum.apache.org/

[4] SVNKit, subversion for java, http://svnkit.com/

[5] Maven Wagon FTP, http://maven.apache.org/wagon/wagon-providers/wagon-ftp/

[6] Martin Fowler, “Continuous Integration”, http://martinfowler.com/articles/continuousIntegration.html

[7] Controllo Versioni,http://it.wikipedia.org/wiki/Controllo_versione

[8] Guida Subversion, Francesco Abeni, programmazione.html.it

[9] The Best Continuous Integration Tools,Vlad Kofman http://www.developer.com/

[10] Hibernate, Wikipediahttp://it.wikipedia.org/wiki/Hibernate

[11] Hibernate, Referencehttp://docs.jboss.org/hibernate/core/3.6/reference/en-US/html_single/

Technology

Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee