Progettazione, sviluppo e gestione del change con modelli UML, framework e strumenti open source

V parte: Il piano della configurazionedi

La serie si conclude parlando di definizione e attuazione del piano della configurazione. Vedremo il modo in cui è possibile attivare una strategia di configurazione di ciascun artefatto di distribuzione della soluzione applicativa, nonché una soluzione di versionamento di ciascun componente e dell'intera soluzione applicativa.

Introduzione

Terminiamo questa serie di articoli con la definizione e attuazione del piano della configurazione. Illustreremo la strategia di configurazione di ciascun artefatto di distribuzione della soluzione applicativa. Questa, basandosi su semplici assunti di isolamento delle attività di realizzazione, bug fixing e di build management, contribuirà a indirizzare la definizione del modello di sviluppo che abbiamo descritto nella prima parte. Verrà anche presentata una soluzione di versionamento di ciascun componente e dell'intera soluzione applicativa.

Definizione e attuazione del piano della configurazione

Il modello di gestione della configurazione adottato prevede l'isolamento, e quindi l'esecuzione in parallelo, delle attività di sviluppo, di distribuzione degli artefatti e di bug fixing. In questi termini sulla mainline di sviluppo (il folder Trunk di SVN) vengono realizzate tutte  le implementazioni stabilite per il rilascio al collaudo. Una volta terminata la realizzazione e conclusi con successo i test unitari, i sorgenti vengono rilasciati al team di gestione della configurazione che provvede alla loro compilazione su un'area (il folder Build di SVN)  isolata, e certificata rispetto alle dipendenze verso i run-time di esecuzione e verso le librerie applicative. Le attività di sviluppo sulla mainline si interromperanno quindi solo per il tempo necessario alla verifica che il codice sorgente sia compilabile: eventuali broken build saranno corrette su questa linea di sviluppo perche' quest'ultima sia sempre coerente. Chiaramente questo discorso non vale per gli artefatti che non necessitano di compilazione (file di configurazione, di risorse, script, etc.). Solo successivamente gli sviluppatori potranno proseguire sulla mainline le attività di codifica programmate.

Una volta compilati, gli artefatti verranno promossi su un branch di release (il folder Release di SVN) e i sorgenti corrispondenti verranno  promossi su un branch (il folder Vxxx di SVN), dove verranno corretti gli eventuali difetti rilevati durante l'esecuzione dei collaudi. Ad ogni nuova compilazione corrisponderà una nuova pubblicazione dell'artefatto sullo stesso branch di release.

Queste correzioni verranno poi propagate sulla mainline con operazioni di merge per rendere coerenti i nuovi sviluppi con quanto corretto durante  la fase di collaudo. Una volta concluso il collaudo, i sorgenti di questa versione verranno etichettati (il folder Tags/Vxxx di SVN)  in corrispondenza  del rilascio del modulo compilato sul progetto di release.

 

 

Figura 1 - Configurazione del repository SVN: 001_RELEASE_TO_BUILD.

 

In figura 1, 2 e 3, abbiamo riportato lo stato del progetto di SVN corrispondente all'applicazione degli Ant di automazione presentati nella IV parte della serie, al paragrafo "Progetti di automazione".

 

 

Figura 2 - Configurazione del repository SVN: 002_BUILD_LIB.

 

Viene quindi stabilita una relazione tra ogni versione di ogni modulo compilato e i corrispondenti sorgenti.

 

 

Figura 3 - Configurazione del repository SVN: 003_TAG_LIB.

 

Riportiamo in figura 4 la rappresentazione grafica delle relazioni tra i compilati pubblicati sul branch di release e i sorgenti corrispondenti.

 

 

Figura 4 - Configurazione del repository SVN: relazione tra artefatti software compilati e sorgenti.

 

Questo approccio, oltre a soddisfare il principio di ripetibilità della compilazione del software, secondo il quale il gestore della configurazione deve essere sempre nelle condizioni di poter ripetere la compilazione di una stabilita versione del software, rappresenta un requisito per uno scenario caratterizzato da una gestione dell'esercibilità con  versioni di software diverse.

Su queste ultime infatti, in caso di manutenzione evolutiva o correttiva, il piano di configurazione presentato permette di poter intervenire in modalità isolata rispetto agli sviluppi correnti. Successive e opportune valutazioni di questi interventi condurranno alla loro eventuale propagazione sulle altre versioni del componente.

Gestione della release complessiva del componente

Ultimato il collaudo del componente, affrontiamo la gestione della sua versione a sua volta dipendente  da quella di ciascuna libreria che lo realizza.

 

 

Figura 5 - Diagramma di struttura composita e artefatti di distribuzione.

 

Se prendiamo in esame gli artefatti di distribuzione descritti nel diagramma di struttura composita presentato nel primo articolo della serie (figura 5) possiamo definire graficamente un ipotetico legame tra la versione di ciascuna libreria e la versione complessiva del componente (figura 6).

 

 

Figura 6 - Definizione del legame tra versionamento delle singoli librerie e versione del componente.

 

Il legame tra versioni diverse dei componenti di una soluzione applicativa viene risolto attraverso specifiche implementazioni native nei sistemi di software configuration management professionali (cito, a titolo di esempio, quello di Rational Clear Case con il costrutto delle baseline composite).

Uso degli sturmenti di versioning "comuni"

Attraverso un semplice artificio potremmo ottenere una funzionalità simile da qualsiasi strumento di versioning. La mancanza di funzioni che legano logicamente gli artefatti in versioni diverse viene spesso aggirata con la pubblicazione di tutte le versioni degli interi bundle di distribuzione dei componenti,  ciascuno dei quali costituito da tutti gli artefatti che realizzano il componente stesso.

Anche se questa scelta permette una immediata individuazione di ogni versione della soluzione applicativa, determina al tempo stesso una grossa ridondanza all'interno dello strumento di gestione del versioning, in quanto la stessa versione di un artefatto viene ripetuta in versioni diverse del componente che realizza (figura 7).

 

 

Figura 7 - Pubblicazione dell'intero bundle di distribuzione.

 

L'arteficio che presentiamo consiste nella pubblicazione, contestuale al rilascio di un artefatto generico, di  un descrittore che referenzia la versione degli artefatti che realizzano il componente.

Nella figura 8 abbiamo riportato un esempio grafico relativo al Servizio01, costituito dalle tre librerie che lo realizzano. Questo descrittore viene quindi pubblicato sul sistema di gestione della configurazione e i puntamenti di cui è costituito verranno utilizzati per risolvere gli artefatti corrispondenti pubblicati sul progetto di rilascio SVN.

 

 

Figura 8 - Corrispondenza tra manifest di release del componente e versione delle singole librerie.

 

Attraverso questa modalità saremo sempre nelle condizioni di ottenere i pacchetti differenziali tra versioni diverse di un componente anche non contigue, oltre che ogni bundle di distribuzione completa, utilizzando il sistema di gestione della configurazione in modo efficiente e senza ridondanze.

Con  l'estensione di questo modello saremo anche in grado di definire tutte le versioni dell'intera soluzione applicativa.

Uno sguardo d'insieme

Abbiamo dunque presentato definizione e applicazione delle strategie di configurazione ritenute necessarie a supportare il ciclo di vita della nostra soluzione applicativa, obiettivo raggiunto attraverso  l'integrazione e l'automazione di SVN, strumento di gestione del versioning,  con il framework Ant.

Quello illustrato è un piano della configurazione basato su semplici assunti di isolamento e responsabilità delle attività di realizzazione in relazione alla loro finalità (sviluppo, bug fixing, patch management, sviluppi differiti, etc.)  e di quelle di rilascio e distribuzione. Principi che lo rendono funzionale a contemperare più aspetti del ciclo di vita, quali l'esercibilità anche in scenari complessi, dove la soluzione applicativa deve essere gestita in versioni diverse, piuttosto che orientare in modo efficace il patch management e le evoluzioni solo sui componenti impattati, anche quando queste ultime vengano prima implementate sotto forma di prototipo.

Orientare in questi termini anche realizzazioni software di livello prototipale o di bassa complessità, laddove invece la percezione immediata è tale da non giustificare i costi da sostenere,  può rappresentare un fattore abilitante nel caso in cui il prototipo evolva e la gestione della configurazione diventi necessaria.

Conclusioni

Chiudendosi con l'attuazione del piano della configurazione, questa serie di articoli ha avuto come obiettivo quello di illustrare la progettazione di una soluzione applicativa, dimostrando che le fasi cardine individuate nella prima parte possono contribuire a traguardare e contemperare obiettivi appartenenti ad ambiti progettuali diversi (sviluppo, collaudo, esercizio, etc.).

Abbiamo messo in relazione le modalità con cui modellazione, progettazione, sviluppo e la gestione della configurazione concorrono insieme a una più efficace conduzione di ciascuna fase del progetto. Nella vita lavorativa reale, però, soprattutto in situazioni non adeguatamente strutturare, spesso le fasi di modellazione o di gestione della configurazione vengono scarsamente prese in considerazione, in quanto erroneamente percepite come improduttive rispetto alla realizzazione in senso stretto.

Possiamo anche affermare che un approccio di questo tipo traguarda anche un importante risultato derivato di tipo economico. In un contesto di questo tipo sarà infatti più agevole creare una più armonica composizione del gruppo di lavoro, che sarà costituito da figure il cui livello professionale e di esperienza sarà quello più appropriato in relazione alla fase progettuale e al gruppo di appartenenza. In questo modo si potrà gestire con maggiore efficacia il turn over dei professionisti impegnati nel progetto che vede una naturale riduzione delle figure senior nel passaggio dalla progettazione, alla realizzazione e alla manutenzione.

È infatti facilmente intuibile un costo maggiore dovuto al maggior numero di risorse con maggiore esperienza professionale e anzianità di progetto, rispetto a una situazione di  progressiva sostituzione di queste con delle figure junior che progressivamente hanno acquisito l'esperienza necessaria.

Questo aspetto, puramente economico, viene completato da uno di tipo sociale corrispondente al livello di gratificazione dei singoli professionisti: questo contesto infatti favorisce una più adeguata collocazione delle risorse su attività di propria soddisfazione, mentre spesso accade che, col sopravvenire di criticità, sono più difficilmente rilasciabili le figure con maggiore professionalità e anzianità di progetto.

Riferimenti

[1] SubVersive

http://www.eclipse.org/subversive/

http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean

 

[2] Rational Clear Case

http://www-01.ibm.com/software/awdtools/clearcase/

 

[3] Serena

http://www.serena.com/

 

 

Condividi

Pubblicato nel numero
180 gennaio 2013
Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’università di Roma e si occupa di informatica da diversi anni. Dopo una lunga esperienza di system integration su piattaforma Java EE e Microsoft in una importante società di consulenza, attualmente si occupa di progettazione e sviluppo su tecnologie distribuite…
Ti potrebbe interessare anche