Configurazione

Software testing
Lezione 8 – Configuration Management
Federica Spiga
[email protected]
A.A. 2010-2011
Autori: F.Spiga
1
Configuration Management
 Attività ausiliaria che abbraccia tutto il processo software.
 Un cambiamento può avvenire in qualunque momento.
 Le attività di Software Configuration Management hanno lo scopo di:
– 1. Riconoscere il cambiamento
– 2. Controllarlo
– 3. Garantire che sia opportunamente implementato
– 4. Riferire agli interessati l’avvenuto cambiamento
2
Definizione (1)
 Secondo lo standard IEEE, la CM (Configuration Management) è il processo di
–
–
–
–
identificazione e definizione di tutte le entità presenti nel sistema
controllo del cambiamento di queste entità in tutto il loro ciclo di vita
registrazione e rilevazione dello stato delle entità e delle richieste di cambiamento
verifica della completezza e della correttezza delle entità
 La definizione dello standard IEEE oggi, però, deve essere ampliata per includere nuove
funzionalità extra dei sistemi CM:
– Manufacturing: gestione della creazione del prodotto software
 Ad esempio: “Quali versioni di file e tool sono stati usati per creare questa versione?”
– Process Management: assicurazione dell’esecuzione corretta delle procedure e del modello
del ciclo di vita
 Ad esempio: “Tutti i file sono stati testati per verificarne la qualità prima di essere consegnati al
cliente?”
– Team Work: controllo del lavoro e delle interazioni tra più sviluppatori su un prodotto
 Ad esempio: “Tutti i cambiamenti dei programmatori apportati localmente sono stati riuniti nell’ultima
versione del prodotto?”

3
Definizione (2)
 Manufacturing
– Environment setup
– è necessario per assicurare un’applicazione corretta delle politiche e favorire la standardizzazione
 Creazione della directory root per il progetto e, all’interno di essa, le directory per lo sviluppo del codice,
per la documentazione, per la gestione ecc.
 Definizione dell’accesso al repository, chi può accedere a esso e con quali diritti nei vari sottoalberi
 Definizione di un ambiente standard di sviluppo
 Definizione di una politica di packaging globale per il prodotto
– Gestione della Build
– Impone l’uso di dipendenze centralizzate, evitando di includere più versioni dello stesso COTS
all’interno di un unico build
 Evita dipendenze circolari
– Packaging
– una volta completato un build, CM integra i componenti in un pacchetto d’installazione comune
 Definire ciò che deve essere compattato è compito degli sviluppatori; ogni componente deve avere il
proprio file di descrizione del packaging, oltre a tutti gli script post installazione necessari
 il pacchetto finale deve essere rilasciato dal Configuration Manager, che identifica e tiene traccia anche
degli strumenti consegnati
4
Lo scopo del Configuration Management
– Lo scopo della gestione della configurazione software è stabilire e
mantenere l’integrità dei prodotti software in tutto il loro ciclo di vita
– La gestione della configurazione software comprende:
 l’identificazione della configurazione del software (cioè quali sono i
prodotti di software selezionati e le loro descrizioni) in un dato momento
 il controllo dei cambiamenti
 il mantenimento dell’integrità e della tracciabilità della configurazione per
tutto il ciclo di vita del software
– CM risponde a domande come:
 Quali sono i componenti del prodotto?
 Come posso assicurare che non vengano fatti cambiamenti disastrosi?
– CM si prende cura del cliente (interno o esterno al progetto), che deve avere la
sicurezza che la versione del prodotto a lui consegnata possa essere mantenuta
correttamente
5
Changes
Cambiamenti nei requisiti
Dati
Altri
Documenti
Codice
Documenti
progetto
6
Configuration Item
Un Configuration Item (CI) è uno
specifico e documentato work product
risultante o usato durante il ciclo di vita
Un work product è un qualsiasi artifatto
tangibile risultante da una attività di
sviluppo.
Es: Piani di progetto, documentazione
test, script di test, codice sorgente, ecc
7
Baseline
Una Baseline è un insieme di uno o più Configuration Item il cui
contenuto è stato sottoposto a revisione tecnica e accettato, in una
fase del ciclo di vita.
E’ la fotografia del progetto in quel determinato istante.
Per ogni Baseline va documentato:
•L’evento che ha creato la baseline
•I CI associati a quella baseline
•Le modifiche fatte alla baseline dalla creazione in poi
•Le procedure usate per definire e modificare la baseline i sui CI
Differenti tipi di Baseline
•Functional
•Allocated
•Development
•Product
8
Functional Baseline
Descrive quali funzioni eseguirà il sistema ed è la configurazione
stabilita dopo la revisione dei requisiti di sistema e la recisione del
design di sistema:
•Insieme iniziale di documenti che specificano le caratteristiche
funzionali dei CI, test di sistema richiesti per verificarle, caratteristiche
delle insterfacce, design constraints, performance richieste
•E’ la prima Baseline che viene costruita (documenti che descrivono le
specifiche del sistema)
•Può essere considerato un “Contratto” tra il team di sviluppo e il
Cliente
9
Allocated Baseline e Development Baseline
Allocated Baseline:
Documenta quali funzioni il software dal sviluppare eseguirà ed è la
configurazione stabilita dopo la revisione dei requirements.
Il termine allocated vuole indicare il concetto che i requisiti sono stati
allocati dalle specifiche di sistema della funcional baseline
Development Baseline:
E’ una baseline interna (le altre sono esterne)
Evolve tra la allocated e la product
•Costruita incrementalmente
•Incorpora tutti i semilavorati del processo di produzione
(documenti di design,
•codice sorgente, eseguibili, casi di test, …)
•Diverse baseline di sviluppo in tempi diversi, sempre più complete
e stabili
10
Product Baseline
E’ la configurazione stabilita dopo le attività di verifica e validazione a
livello sistema che confermano il soddisfacimento dei requisiti (SRS e
SDD).
E’ la baseline che documenta in modo completo la versione finale del
software.
E’ usata per supportare le versioni rilasciate del prodotto; è il punto di
partenza per lo sviluppo delle release successive.
•Codice sorgente e tutto ciò (documentazione e tool di supporto)
che serve per “ricostruire” il prodotto e manutenere il codice
•Costituita dopo il test di accettazione del prodotto
•Costituisce ciò che viene rilasciato al cliente
11
Configuration Control Board
• Persona o commissione che coordina ed autorizza le modifiche da
apportare ad una baseline per cui è competente
• Effettua le valutazioni dell’impatto di cambiamenti (non solo da un
punto di vista tecnico ma anche logistico, strategico, economico e
organizzazionale) alla baseline
L’obiettivo è di mantenere una visione globale e valutare l’impatto al
di la della baseline in questione
•Più CCB, ognuna competente per una particolare baseline,
eventualmente organizzate gerarchicamente
•Istituite in modo da assegnare precise responsabilità e ridurre il
numero di persone da riunire per discutere le possibili soluzioni ad
un problema
12
Le attività di CM
 Configuration Identification
 Configuration Control
 Configuration Status Accounting
 Configurations Audits & Review
 Interface Control
 Subcontractor Vendor Control
13
Configuration Identification
 Attività in cui i software configuration items sono
– determinati
– Univocamente identificati e nominati
– catalogati
 Descrive come i meccanismi di revisione e rilascio sono usati per porre il sw sotto il
controllo di configurazion
 Due livelli di identificazione
– Logica: Codice/Nome del documento, modulo, sorgente, …
– Fisica: Nome del file contenente il testo del documento, modulo,…
14
Configuration Identification
Esempi:
Sorgente C++
– Identificazione logica: modulo = classe, nome della classe
– Identificazione fisica (nome del file):
• file header con dichiarazione: nome della classe . h
• file con implementazione: stesso nome dell’header . Cxx
un modulo => 2 file
Documento di Specifica
Definizione di regole per asseganzione identificatori/nomi
<codice autore> - <codice del progetto> - <versione> - <stato>
<titolo> - <tipo di doc> - <versione> + <stato> - <codice progetto>
15
Configuration Control
 Descrive le procedure che sono utilizzate per il controllo del
cambiamento della documentazione e del codice
conseguente da porre sotto il controllo della
configurazione.
 Descrive le revisioni per le richieste di cambiamento fatte
da un organismo di revisione, quale il CCB, della
configurazione e include la lista dei componenti di tale
commissione e loro eventuali alternative
16
Configuration Control
Richieste di modifiche
•Classificazione
richiesta
Valutazione della
richiesta
•Software change classification
• Technical Impact Analysis
•Identificazione
• Interface Impact Analysis
•Validazione della
richiesta
• Schedule Impact Analysis
• Budget Impact Analysis
Approvazione/Non
approvazione della
modifica
•Decision (if approved)
• Implementation Assignment
• Verification Assignment
• Release/Installation
Assignment
• Version upadate
Implementazione della
modifica
•Check-out Controlled Baseline
• Change Implementation
• Implementation testing &
verification
• Implementation approval
• Check-in Controlled Baseline
17
Check In & Check Out
 Check IN
– Deposita una nuova versione di un CI nel repository
– Possibile una serializzazione del lavoro
 Si può decidere se solo uno sviluppatore alla volta
può effettuare dei cambiamenti (mettendo un lock
al file) oppure più sviluppatori possono lavorare in
parallelo e si effettua il “merge” delle versioni
 Check OUT
 preleva una copia di una versione di un modulo da
un repository e la deposita nello spazio di lavoro
– criteri per la selezione della versione (ultima, x.y, data, …)
– possibilità di porre o meno un lock sulla specifica versione
(lock = modifica possibile)
 Modifica della copia nello spazio di lavoro
(isolamento)
18
Modello Lock/Modify/Unlock
 In principio, l’unico modello secondo il quale più programmatori accedevano in
concorrenza ai diversi file di un progetto era il modello “lock/modify/unlock”.
 Secondo questo modello un utente che vuole modificare un file del progetto,
prima di tutto lo blocca (lock), impedendo a chiunque altro di modificarlo,
dopodichè, quando ha terminato le modifiche lo sblocca (unlock).
 Questa strategia, per quanto garantisca la massima sicurezza da problemi di
manomissione contemporanea involontaria, non ottimizza nel modo migliore le
operazioni.
Adoperando questo modello, si tende a spezzettare il più possibile un progetto,
in modo da ridurre gli impedimenti al lavoro causati dai lock.
19
Modello Copy/Modify/Merge
 Il modello Copy/Modify/Merge
prevede che:
– Lo sviluppatore A scarica una copia
del progetto (working copy o sandbox)
dal repositpry centrale;
– Applica liberamente tutte le
modifiche. Nel frattempo altri
programmatori (B) potrebbero fare lo
stesso;
– Al termine del suo lavoro il
programmatore A aggiorna il progetto
sul repository centrale (commit);
– Altri programmatori potrebbero
richiedere aggiornamenti della loro
working copy (update) al repository o
generare delle ulteriori versioni
(commit).
20
Software Configuration Management
 Versione
– Stato di un elemento in un istamte di tempo
 Configurazione
– Insieme di CI utilizzati per costruire un prodotto
 Release
– Una istanza di un sistema distribuita agli utenti esterni
21
Identificazione della Versione
 Le procedure per l’identificazione delle versioni devono definire un modo
non ambiguo per identificare le componenti della versione
 Una tecnica base per la identificazione delle componenti è
– Numerazione delle versione
 V1, V1.1, V2, V2.1 ecc
 Può portare ad errori in quanto i nomi non sono significativi
 Meglio utilizzare un a struttura ad albero piuttosto che una sequenza
22
Identificazione multi-livello
 Identificazione gerarchica di Configuration Item
– Un esempio: la terminologia corretta definita è obbligatoria
23
Revisione e Variazione
 Revisione
– la versione M’ di un modulo è una revisione di M se M’ sostituisce M in tutte le
configurazioni cui M appartiene a partire dal momento in cui M’ risulta disponibile
(es. correzione di errori)
 Variazione
– la versione M’ è una variazione di M se M’ è un’alternativa ad M in situazioni
particolari (es. supporto periferiche diverse)
 Due configurazioni differiscono se contengono elementi diversi
 Due configurazioni differiscono anche se contengono due versioni più o meno
diverse dello stesso modulo (contenuto diverso)
 Lo stesso modulo può far parte di più configurazioni
 Versioni delle configurazioni
24
Gestione dello stato
 Viene fornita a tutti una descrizione costantemente aggiornata
dello stato degli artefatti su cui si sta lavorando
– Ogni azione sui Configuration Item deve archiviare il nuovo stato degli item così
che tutti ne siano avvisati (in tempo reale, ad esempio attraverso la pagina Web
del progetto)
 Vengono generati report dello stato della configurazione del
progetto
– CM consegna periodicamente il Configuration Report che fornisce una
panoramica dello stato della configurazione del progetto
25
Configuration Audits & Reviews
 Configuration Audits & Reviews
– Conduzione di riunioni formali in cui il sistema, o sue parti, sotto SWCM è controllato, verificato
e validato rispetto alle attività di SWCM
 Configuration Status Accounting
– Processo per esaminare il sistema di SWCM ed i suoi contenuti, inclusa la cronistoria dei
cambiamenti
 Informazioni minime da registrare:
– La versione iniziale di un SCI
– Lo stato di tutte le modifiche richieste per ogni SCI
– Lo stato di implementazione di tutte le modifiche approvate per gli SCI
26
Tool di Configuration Management
 Due tipologie principali:
 Workbench aperti
– Si tratta di strumenti stand-alone che si occupano di uno degli aspetti della gestione delle
versioni e delle release
– Spesso si tratta di strumenti open source
– Strumenti di bug-tracking (es.: Bugzilla)
– Strumenti di gestione delle versioni (es. CVS)
– Strumenti per il build (es. make, ant)
 Workbench integrati
– Si tratta di strumenti che vanno a integrarsi con gli ambienti di sviluppo in modo da
supportare la gestione di versioni e release contestualmente allo sviluppo
– Rational Clear Case e Clear Quest
– Microsoft Source Safe
– Strumenti integrati in NetBeans, Eclipse, Dev
27
CVS: Concurrent Version System
 Sistema di controllo delle versioni di un progetto legato alla produzione e alla
modifica di file. In pratica, permette a un gruppo di persone di lavorare
simultaneamente sullo stesso gruppo di file (generalmente si tratta di sorgenti
di un programma), mantenendo il controllo dell'evoluzione delle modifiche che
vengono apportate.
 Per attuare questo obiettivo, il sistema CVS mantiene un deposito centrale
(repository) dal quale i collaboratori di un progetto possono ottenere una copia
di lavoro. I collaboratori modificano i file della loro copia di lavoro e
sottopongono le loro modifiche al sistema CVS che le integra nel deposito.
 ll compito di un sistema CVS non si limita a questo; per esempio è sempre
possibile ricostruire la storia delle modifiche apportate a un gruppo di file, oltre
a essere anche possibile ottenere una copia che faccia riferimento a una
versione passata di quel lavoro.
 http://www.nongnu.org/cvs/
28
CVS: Concurrent Version System
 Il sistema CVS è un software, presente per diversi sistemi operativi, che
consente di gestire a linea di comando le principali operazioni previste dai
modelli lock/modify/unlock e copy/modify/merge.
 Il lato server gestisce il repository, contenente sia tutti I file da gestire che tutte
le informazioni sulle versioni.
In alternativa il deposito potrebbe anche trovarsi sulla macchina client.
 Il lato client consente di effettuare tutte le operazioni riguardanti la copia
locale (sandbox) del progetto.
29
CVS- Gestione Conflitti
 Nel caso in cui due programmatori modificano lo stesso file, il sistema CVS può
fondere (merge) le due versioni, sovrapponendo le modifiche, allorchè si
riferiscano a linee di codice diverse.
 Se invece ci sono modifiche alle stesse righe di codice si verifica un conflitto.
 La soluzione del conflitto è in questo caso demandata ai singoli
programmatori: la versione unificata che viene generata diventa la nuova
versione di riferimento.
In alternativa si potrebbe scegliere di mantenere entrambe le versioni come
alternative, generando un branch.
30
CVS- Operazioni
 Ogni persona coinvolta nel progetto, ha una copia locale dei file
(sandbox).
 Chi avvia il progetto crea per la prima volta il repository (Make
new module), indicando anche quali directory dovranno essere
gestite.
 Successivamente un qualsiasi collaboratore può aggiungere nuovi
file/directory al CVS (add).
 Un collaboratore che voglia inserirsi nel CVS dovrà per prima cosa
effettuare il Checkout per prelevare dal repository le versioni più
recenti di ogni file.
31
CVS- Operazioni
 Sui file presenti nella propria sandbox si possono effettuare le seguenti
operazioni:
 Checkout (o update): preleva una copia aggiornata dal repository;
– Se copia locale e copia del repository non coincidono viene segnalato un conflict;
– Dopo il checkout, la copia locale è in stato di lock e non può essere modificata.
 Edit: richiede il permesso di scrivere sul file locale
– Se il file è già in stato di edit da parte di qualche altro utente, viene segnalato il rischio di
modifiche concorrenti (nel caso di file binari o di politica di lock/modify/unlock viene
impedito l’accesso).
 Commit: rende pubbliche a tutti le proprie modifiche al file
– Le modifiche vengono propagate al repository. Il repository incamera il file ricevuto come
nuova versione; le versioni precedenti rimangono reperibili.
32
CVS- Operazioni
Gestione conflitti
 Se due utenti vanno a modificare in concorrenza lo stesso file, e il primo di essi
effettua il commit, verrà impedito al secondo di fare lo stesso
– In questo caso si consiglia al secondo di fare un update: il sistema nota la differenza tra la
versione sul repository e quella locale e popone alcune soluzioni semiautomatiche (merge)
per la soluzione dei conflitti. Al termine, il secondo utente avrà una versione locale che tiene
conto sia delle proprie modifiche che di quelle degli altri utenti. Di questa versione potrà
essere fatto il commit, ottenendo quindi una versione successiva.
Generazione branch
 Genera un ramo “alternativo” nella storia del file (se ne terrà conto nella
diversa numerazione: ad esempio dopo 1.2 ci sarà 1.2.1 anzichè 1.3)
– Sono disponibili funzionalità per vedere graficamente tutta la “storia” delle versioni del files.
 Fusione tra versioni diverse. Eliminazione copia locale. Eliminazione originale
(da operare direttamente sul repository).
33
CVS- Tag
 Ogni versione può essere annotata e ad essa possono essere aggiunte delle
informazioni dette tag. I tag sono particolarmente utili per distinguere tra loro
le release di un software
34
TortoiseCVS
 TortoiseCVS è un front-end client che rende l’uso di CVS pù semplice, più
intuitivo e più produttivo. Si interfaccia direttamente con Windows Explorer™.
 One dei maggiori vantaggi è quello di mostrare, per ogni comando dato da
interfaccia, le corrispondenti operazioni a linea di comando effettuate.
 TortoiseCVS non include un CVS Server ma supporta la creazione di repository
CVS locali.
 Tortoise CVS supporta anche una serie di operazioni di più alto livello
–
–
–
–
–
–
–
Gestione dei conflitti
Cronologia delle versioni
Grafo delle versioni
Creazione di patch
Scelta delle politiche di accesso
Operazioni in batch
…
 http://www.tortoisecvs.org/
35
SubVersion
 Subversion è un sistema di controllo versione progettato da CollabNet Inc.
con lo scopo di essere il naturale successore di CVS
 Caratteristiche principali:
– Comprende gran parte delle caratteristiche di CVS.
 Novità rispetto a CVS
–
–
–
–
–
–
–
Le directory, i cambi di nome, e i metadati dei file sono sotto controllo versione.
Il controllo di versione avviene anche sulle directory
Un file che era stato precedentemente rimossopuò essere aggiunto nuovamente
I file binari sono gestiti efficientemente
Il protocollo client/server invia solo le differenze in entrambe le direzioni
I commit sono atomici
Diverse modalità di accesso al repository
36
SubVersion
 Sito Ufficiale Subversion: http://subversion.apache.org/
 Sito Italiano Subversion: http://www.subversionitalia.it/
 Al seguente link può essere scaricato l’ebook “Controllo di versione con
SubVersion” http://svnbook.red-bean.com/index.it.html
 Esiste TortoiseSVN, analoga a TortoiseCVS che abilita le funzionalità SVN
direttamente da Windows Explorer http://tortoisesvn.tigris.org/
37
Best Practice
 I [Merge] vanno fatti sempre in locale, poi si spedisce il risultato
sul server
 Eseguire [Update] di frequente e integrare spesso le modifiche
sul server
 Eseguire il [Commit] solo di codice perfettamente compilabile
– Testare a fondo prima del commit
38