La nostra serie si avvia a conclusione. Con questo e con il prossimo articolo affronteremo il piano di configurazione. In particolare, in questa quarta parte ci occupiamo di comprendere gli elementi necessari alla definizione del piano di configurazione e di scegliere e configurare lo strumento di gestione della configurazione.
Introduzione
Il piano della configurazione è l’ultimo argomento affrontato da questa serie di articoli. Ne affronteremo la trattazione in questo articolo e nel prossimo: in questa sede individueremo gli elementi che concorrono alla sua definizione, completando il workspace di sviluppo con i progetti di automazione necessari alla sua attuazione. Sempre in questa parte verrà anche scelto e configurato lo strumento di gestione della configurazione.
Nella prossima e conclusiva parte, verranno definiti e attuati i processi che costituiscono il piano della configurazione della nostra soluzione applicativa.
Il piano della configurazione
L’individuazione degli elementi di configurazione di una soluzione applicativa rappresenta il prerequisito alla definizione del piano della configurazione. Con il termine elementi di configurazione ci riferiamo a tutti gli artefatti software di qualsiasi natura, file eseguibili, di configurazione, di risorse, script, etc., che costituiscono una soluzione applicativa completa. Anche i sistemi e i middleware di esecuzione rappresentano a loro volta elementi di configurazione. È attraverso l’individuazione e la gestione di tutti gli elementi di configurazione, siano essi di natura software, hardware, middleware di esecuzione o sistemi operativi, che sarà possibile definire un modello logico completo di ogni soluzione applicativa.
Perche’ un piano della configurazione sia efficace, questo si deve declinare in processi che rendano armonici i requisiti espressi dai gruppi di lavoro coinvolti nel ciclo di vita di una soluzione applicativa. Si tratta di requisiti derivati dalla criticità delle funzioni applicative, espressi dagli utenti, di requisiti relativi alla distribuzione e alla gestione dei nodi, espressi dai team che gestiscono l’esercibilità, di requisiti legati alla stabilità dell’ambiente e coerenza dei rilasci durante il test, espressi dal collaudo, di requisiti legati all’architettura e alle tecnologie di sviluppo, espressi dai team di realizzazione e di requisiti che soddisfino un piano della configurazione di effettivo supporto al ciclo di vita, espressi questi ultimi dal team di gestione della configurazione.
Sarà il contemperamento di questi requisiti che definirà un processo flessibile che supporti le esigenze di ogni gruppo di lavoro ma che dovrà essere anche capace di adattarsi a eventuali esigenze future. Piani inutilmente complessi sono destinati a rivelarsi inefficaci, così come risulterebbero inadeguati piani troppo generici.
Nel nostro esempio consideriamo adeguato un piano della configurazione che soddisfa i seguenti requisiti che enunciamo di seguito e raggruppiamo in tre categorie.
Requisiti relativi all’organizzazione dello sviluppo e del collaudo
A seguito di un rilascio completo della prima versione della soluzione applicativa, ogni aggiornamento verrà realizzato e rilasciato secondo un modello di sviluppo per feature (una nuova funzionalità o l’evoluzione di una esistente) o bug fixing.
Il processo di collaudo (funzionale, utente, prestazionale, di non regressione) sarà applicato in modo flessibile in relazione al tipo di aggiornamento oggetto del rilascio. Lo scenario di collaudo è chiaramente diverso nel caso di rilasci dai contenuti tecnico/prestazionali rispetto a rilasci funzionali; questi ultimi a loro volta determinano scenari diversi in caso siano relativi a componenti applicativi piuttosto che di infrastruttura.
Requisiti di gestione della configurazione.
Ogni elemento di configurazione del software sarà archiviato e versionato sullo strumento di gestione della configurazione.
Gli artefatti software eseguibili verranno compilati in un ambiente certificato e isolato.
Lo strumento di gestione della configurazione dovrà essere tale da garantire, per gli eseguibili, la ripetibilità di compilazione di ogni versione rilasciata; gli eseguibili risultanti dovranno essere funzionalmente equivalenti.
Lo strumento di gestione della configurazione dovrà garantire la corrispondenza di ogni elemento di configurazione del software eseguibile con il corrispondente codice sorgente.
Requisiti di esercibilità
La garanzia che gli ambienti di esecuzione rimangano inalterati durante la fase a questi dedicata.
Una adeguata gestione dei bug di esercizio, differenziata per livello di criticità del componente con un’efficacia corrispondente;
L’adozione dei politiche di distribuzione coerenti e funzionali alla topologia degli ambienti di esecuzione.
Il team di gestione della configurazione
Abbiamo visto che la definizione del piano della configurazione rappresenta la convergenza di requisiti espressi dai vari gruppi di lavoro coinvolti nel ciclo di vita di una soluzione applicativa. Sarà responsabilità del gruppo che gestisce la configurazione codificarne i processi di cui avrà anche la responsabilità di attuazione. Ciò a completamento delle attività di gestione del sistema di versionamento e di supporto agli scenari di sviluppo, adeguando, laddove necessario, le strategie di gestione della configurazione.
Per rendere la nostra trattazione più leggibile, abbiamo assegnato a questo gruppo anche la responsabilità di realizzare i progetti di automazione, di eseguire le attività di compilazione del codice sorgente e di distribuire gli artefatti sugli ambienti previsti, garantendo inoltre che questi ultimi rimangano invarianti dal punto di vista della configurazione.
Per progetti complessi o in un contesto organizzativo di grandi dimensioni, queste attività vengono attribuite a gruppi specifici.
Gestione della configurazione: scelta e progettazione dello strumento
Per la gestione delle versioni del software e per il controllo di revisione useremo Apache Subversion, strumento distribuito sotto una licenza open source, meglio noto attraverso l’acronimo SVN. Senza entrare nel dettaglio di questo strumento che merita uno spazio adeguato, ne accenniamo le caratteristiche principali. Attraverso Subversion possiamo implementare linee separate di sviluppo etichettando a piacere qualsiasi stato del repository. Ogni linea di sviluppo conserva tutte le versioni dei file che la costituiscono a partire dal momento in cui è stata creata, ex-novo o “staccata” da una etichetta di un’altra linea di sviluppo. Le modifiche attuate in ogni linea di sviluppo possono essere riportate su qualsiasi altra linea attraverso l’operazione di merge.
In corrispondenza della definizione del piano della configurazione, il gruppo di gestione della configurazione definirà la configurazione dello strumento per ogni elemento di configurazione individuato dal modello dei componenti della soluzione applicativa. Riportiamo di seguito l’organizzazione di SVN per una delle librerie di un componente. In blu abbiamo evidenziato il progetto di sviluppo Eclipse.
Figura 1 – Configurazione del repository SVN.
Branches
Nella cartella Branches verranno create tutte le branch che saranno utilizzate come linee di sviluppo isolate. Queste saranno utilizzate per:
- sviluppi differiti a partire da una generica etichetta;
- sviluppi necessari alla stabilizzazione di versioni rilasciate in collaudo;
- sviluppi necessari alla correzioni di difetti di esercizio.
Sarà poi il piano della configurazione che stabilirà le modalità con cui questi contributi saranno propagati sulla linea di sviluppo principale o verso altri branch.
Build
Rappresenta l’area di compilazione nel caso di un elemento di configurazione in formato eseguibile. Si tratta di una branch che viene inizializzata ad ogni compilazione. Rispetto all’uso di una cartella del file system, attraverso un branch di SVN siamo nelle condizioni di poter utilizzare tutte le funzioni di controllo dello strumento.
Release
La cartella Release conterrà l’artefatto software oggetto di configurazione. In questo caso si tratta di un elemento di configurazione di tipo compilato che corrisponde quindi a un gruppo di sorgenti rilasciati.
ReleaseApp
Conterrà, raggruppati in un bundle di distribuzione, tutti gli artefatti software che costituisco il componente applicativo, nel nostro caso il Servizio01.
Tags
Tags contiene genericamente tutte le etichette di rilascio. Nell’attuazione del nostro piano della configurazione, quelle che corrispondono alle versioni dell’elemento di configurazione rilasciato al collaudo.
Trunk
Rappresenta la linea di sviluppo principale. Il piano di configurazione adottato prevede che su questa linea di sviluppo vengano realizzate le implementazioni programmate.
Progetti di automazione
In corrispondenza del piano della configurazione vengono realizzati alcuni progetti di automazione applicando un’integrazione fra i framework Ant e SVNKit. Riportiamo di seguito la descrizione di questi script che guideranno l’operatività di attuazione del piano della configurazione.
001_RELEASE_TO_BUILD
Consiste nel rilascio dei sorgenti dalla mainline di sviluppo al branch su cui ne verrà fatta la compilazione.
1) AGGIORNA IL BRANCH DI BUILD A PARTIRE DALLA MAINLINE DI SVILUPPO
2) CREA UN BRANCH DI APPOGGIO CON I SORGENTI CORRISPONDENTI ALLA LIBRERIA COMPILATA
value="C:/Programmi/svnant-1.2.1/svnant-1.2.1/lib"/>
value="127.1.1.1"/>
value="8085"/>
value="100"/>
classname="org.tigris.subversion.svnant.SvnTask"
classpathref="svnant.classpath" />
username="Deployer01"
password="Deployer01" >
dir="../SERVIZIO01_IFACE_BUILD/"/>
<copy
srcUrl="https: //${env.NOME_SERVER}:${env.PORTA}/
svn/Applicazione01/Server/Servizio01/Iface/trunk"
destPath="../SERVIZIO01_IFACE_BUILD/">
dir="../SERVIZIO01_IFACE_BUILD/"/>
002_BUILD_LIB
Rappresenta lo script di compilazione integrato da tutti i test JUnit previsti (omessi per leggibilità, ma che il lettore potrà esaminare nella parte precedente ). Una volta che la compilazione e l’esportazione della libreria sarà andata a buon fine , quest’ultima verrà pubblicata sul branch di rilascio corrispondente. Contestualmente viene anche creato un branch dove applicare in modo isolato gli eventuali cicli di correzione corrispondenti alle attività di collaudo.
/ant-contrib-1.0b3.jar"/>
SERVIZIO_01_IFACE
1) AGGIORNA L'AREA SVN DI COMPILAZIONE
2) COMPILA LE CLASSI
3) ESPORTA LA LIBRERIA
4) PUBBLICA IN SVN LA LIBRERIA SUL BRANCH DI RELEASE DEL COMPONENTE
5) PUBBLICA SU UN BRANCH DI SVN I SORGENTI CORRISPONDENTI
ALLA LIBRERIA DI CUI AL PUNTO PRECEDENTE
value="D:/Programmi/svnant-1.2.1/svnant-1.2.1/lib"/>
value="127.1.1.1"/>
value="8085"/>
value="100"/>
value="Deployer01"/>
value="Deployer01"/>
classname="org.tigris.subversion.svnant.SvnTask"
classpathref="svnant.classpath" />
username="Deployer01" password="Deployer01" >
description="Compila le classi che implementano la libreria">
it/luigibennardis/servizio01/dto:
../SERVIZIO01_IFACE_BUILD/trunk/
it/luigibennardis/servizio01/iface"
destdir="./build" />
username="${user}" password="${password}" >
description="Esporta il jar con le classi compilate">
basedir="./build" />
<!—PUBBLICAZIONE DELLA LIBRERIA SUL BRANCH DI RELEASE -->
failonerror="true"
username="${user}" password="${password}" >
message="UPDATED COMMIT ESEGUITA
v${build.VERSION}"/>
failonerror="true"
username="${user}" password="${password}" >
message="ADDED FILE COMMIT ESEGUITA
v${build.VERSION}"/>
username="Deployer01"
password="Deployer01" >
svn/Applicazione01/Server/Servizio01/Iface/branches/v${build.VERSION}"
message="CREAZIONE BRANCH: v${build.VERSION}" />
srcUrl="https://${env.NOME_SERVER}:${env.PORTA}/
svn/Applicazione01/Server/Servizio01/Iface/trunk/"
destUrl="https://${env.NOME_SERVER}:${env.PORTA}/
svn/Applicazione01/Server/Servizio01/Iface/branches/
v${build.VERSION}"
message="AGGIORNAMENTO BRANCH v${build.VERSION}"
/>
003_TAG_LIB
A conclusione con esito positivo del collaudo della libreria, questo script ne etichetterà il codice sorgente corrispondente.
/ant-contrib-1.0b3.jar"/>
TAG_VERSIONE
PUBBLICA I SORGENTI DELLA LIBRERIA AL TERMINE DEL COLLAUDO
value="D:/Programmi/svnant-1.2.1/svnant-1.2.1/lib"/>
value="127.1.1.1"/>
value="8085"/>
value="100"/>
classname="org.tigris.subversion.svnant.SvnTask"
classpathref="svnant.classpath" />
username="Deployer01"
password="Deployer01" >
<mkdir
url="https://${env.NOME_SERVER}:${env.PORTA}/svn/Applicazione01
/Server/Servizio01/Iface/tags/v${build.VERSION}"
message="CREAZIONE TAG DIR v${build.VERSION}" />
svn/Applicazione01/Server/Servizio01/Iface/branches/
v${build.VERSION}/trunk"
destUrl="https://${env.NOME_SERVER}:${env.PORTA}/
svn/Applicazione01/Server/Servizio01/Iface/tags/
v${build.VERSION}"
message="load dir v${build.VERSION}"
/>
/svn/Applicazione01/Server/Servizio01/Iface/branches
/v${build.VERSION}"
message="CANCELLAZIONE BRANCH v${build.VERSION}"
/>
Di seguito riportiamo le librerie di dipendenza dell’Ant di automazione. Abbiamo evidenziato nel riquadro rosso quelle relative al framework SVNKit.
Figura 2 – Configurazione del classpath di esecuzione dei task di Ant.
Conclusioni parte quarta
In questa parte abbiamo preso in esame alcuni aspetti che concorrono alla definizione del piano della configurazione. È stato anche scelto e configurato lo strumento di gestione del versionamento e sono stati implementati i corrispondenti progetti di automazione.
Abbiamo anche individuato le figure professionali a cui viene affidata la responsabilità di definire e attuare il piano della configurazione. In questo contesto, il gestore della configurazione, disponendo di una vista di insieme della soluzione applicativa, riveste un ruolo strategico che gli permette di ottimizzare i processi di gestione delle evoluzioni e dei difetti del software.
Sulla base degli obiettivi e requisiti espressi in questa parte, nella prossima e ultima puntata definiremo e attueremo i processi che costituiscono il piano della configurazione.
Riferimenti
[1] SubVersive
http://www.eclipse.org/subversive/
http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean
[2] SVNKit
[3] Rational Clear Case
http://www-01.ibm.com/software/awdtools/clearcase/
[4] Serena