Porfirio Tramontana » 23.Gestione della configurazione

Gestione della configurazione

La gestione della configurazione è un’attività fondamentale per ogni software.

I sistemi software non vengono mai realizzati tutti in una volta:

• Cicli di vita evolutivi;
• Cicli di vita XP, nei quali si forza una integrazione delle parti del software molto frequente (“nightly build”), allo scopo di evidenziare al più presto eventuali problemi di integrazione.

Dopo essere stati rilasciati, essi sono soggetti a numerosi interventi di manutenzione dovuti ad errori, cambiamento dei requisiti, estensioni, etc.
Spesso, inoltre, uno stesso software necessita di essere rilasciato in diverse configurazioni:

• Versioni complete e versioni ridotte;
• Versioni in diverse lingue;
• Aggiornamento di versioni;
• Versioni diverse per diverse configurazioni hardware.

Gestione delle release

Una release di un sistema è una sua versione che viene distribuita ai clienti. Essa comprende, tra l’altro:

• Codice eseguibile
• File di configurazione
• Programma di installazione
• Documentazione elettronica e cartacea
• Imballaggio e pubblicità
• …

Il processo di creazione e rilascio di una release deve quindi riuscire a gestire la generazione di tutti questi deliverables.
In particolare, bisogna decidere se distribuire l’intero sistema oppure se distribuire unicamente delle patch di aggiornamento.

Identificazione delle versioni

• Numerazione
  • #versione.#modifica.#variazione.
• Identificazione basata su attributi
  • Le modifiche vengono etichettate con attributi (eventualmente ordinati), in modo da poter caratterizzare anche l’impatto della modifica oltre che l’ordine delle versioni.
• Identificazione orientata alle modifiche
  • Le modifiche al sistema vengono etichettate in base alle modifiche sui singoli componenti.

Strumenti CASE a supporto

Due tipologie principali:

1. 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)
2. 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

CVS: Concurrent Versioning 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.

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.

Modello Copy/Modify/Merge

In alternativa, il modello Copy/Modify/Merge prevede che:

1. Lo sviluppatore A scarica una copia del progetto (working copy o sandbox) dal server CVS (repository);
2. Applica liberamente tutte le modifiche. Nel frattempo altri programmatori (B) potrebbero fare lo stesso;
3. Al termine del suo lavoro il programmatore A aggiorna il progetto sul server CVS (commit);
4. Altri programmatori potrebbero richiedere aggiornamenti della loro working copy (update) al repository o generare delle ulteriori versioni (commit).

Modello Copy/Modify/Merge (segue)

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.

CVS

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.

Operazioni CVS

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.

Operazioni CVS (segue)

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.

Operazioni CVS (segue)

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

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

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 (segue)

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

(riferirsi al manuale utente per una descrizione completa).