Software testing. Lezione 8 Configuration Management Federica Spiga federica_spiga@yahoo.it. A.A Autori: F.Spiga

Transcript

1 1 Software testing Lezione 8 Configuration Management Federica Spiga federica_spiga@yahoo.it A.A Autori: F.Spiga

2 2 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

3 3 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?

4 4 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

5 5 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

6 6 Changes Cambiamenti nei requisiti Dati Altri Documenti Codice Documenti progetto

7 7 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

8 8 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

9 9 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

10 10 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

11 11 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

12 12 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

13 13 Le attività di CM Configuration Identification Configuration Control Configuration Status Accounting Configurations Audits & Review Interface Control Subcontractor Vendor Control

14 14 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,

15 15 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>

16 16 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

17 17 Configuration Control Richieste di modifiche Classificazione richiesta Identificazione Validazione della richiesta Valutazione della richiesta Software change classification Technical Impact Analysis Interface Impact Analysis 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

18 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

19 19 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.

20 20 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).

21 21 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

22 22 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

23 23 Identificazione multi-livello Identificazione gerarchica di Configuration Item Un esempio: la terminologia corretta definita è obbligatoria

24 24 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

25 25 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

26 26 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

27 27 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

28 28 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.

29 29 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.

30 30 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.

31 31 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.

32 32 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.

33 33 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à 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).

34 34 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

35 35 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

36 36 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

37 37 SubVersion Sito Ufficiale Subversion: Sito Italiano Subversion: Al seguente link può essere scaricato l ebook Controllo di versione con SubVersion Esiste TortoiseSVN, analoga a TortoiseCVS che abilita le funzionalità SVN direttamente da Windows Explorer

38 38 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