Gli spazi di lavoro si riferiscono a delle aree 'private' in cui gli sviluppatori possono implementare e testare il
codice in conformità con gli standard adottati del progetto in relativo isolamento dagli altri sviluppatori. Il
responsabile della configurazione deve creare un ambiente di spazio di lavoro per ogni sviluppatore del progetto.
Uno spazio di lavoro fornisce ad ogni sviluppatore un ambiente coerente, flessibile, economico e riproducibile che
seleziona e presenta la versione appropriata di ogni file. E' necessario che lo spazio di lavoro sia in grado di
fornire un controllo a granularità sottile sia sulla condivisione che sull'isolamento. Ciò è richiesto in quanto nella
maggior parte dei progetti, è necessario che gli sviluppatori restino isolati dalle modifiche effettuate da altri; ma
allo stesso tempo, è necessario che siano in grado di eseguire la verifica unità delle modifiche da loro apportate con
quelle eseguite da altri sviluppatori.
Quando si esegue la manutenzione su rilasci precedenti, è necessario che uno sviluppatore sia in grado di visualizzare
le vecchie versioni, i file binari, i documenti, i test, i tool e gli altri oggetti. In questo caso lo spazio di lavoro
serve come una 'macchina del tempo' rendendo tutto ciò che è contenuto nell'ambiente, tranne le origini, come se fosse
eseguito nel passato.
E' necessario isolare ogni spazio di lavoro dello sviluppatore, per le modifiche, la compilazione, la verifica e
l'esecuzione del debug. Tuttavia, l'isolamento dello spazio di lavoro deve essere relativo e non assoluto:
-
E' necessario tenere traccia del lavoro di uno sviluppatore ed integrarlo selettivamente nel proprio.
-
E' necessario essere in grado di chiudere. Fino ad un periodo di integrazione successivo quelle modifiche
potrebbero destabilizzare il proprio lavoro.
E' possibile che uno spazio di lavoro sia completamente privato per uno sviluppatore singolo oppure condiviso tra un
team di sviluppatori su una rete.
Oltre che fornire l'accesso alle versioni di origine, è necessario che uno spazio di lavoro fornisca una memoria
privata (isolata) per i file generati durante lo sviluppo del software:
-
Versioni in esecuzione (assegnate) di file di origine,
-
file eseguibili,
-
Altri oggetti privati dello spazio di lavoro - codice di origine, directory secondarie di test e file di dati di
test.
Una memoria provata dello spazio di lavoro può essere ubicata di solito all'interno della directory principale dello
sviluppatore su una workstation. E' possibile che uno spazio di lavoro condiviso da un gruppo di sviluppatori disponga
di un'area di memorizzazione privata situata su un server file centrale. Tuttavia, l'ubicazione effettiva della memoria
privata è ampiamente irrilevante. Dal punto di vista dello sviluppatore, è necessario che la memoria privata dello
spazio di lavoro venga visualizzata come completamente integrata.
La figura precedente illustra la nozione di spazi di lavoro di integrazione e privato nel contesto generale del cubo
CM.
Le configurazioni di lavoro (profili dello spazio di lavoro) fanno riferimento a sottosistemi particolari che creano un
working set per il processo. Un working set è un elenco di versioni specifiche di sottosistemi che è
necessario siano di riferimento oppure vengano modificati per implementare una parte del lavoro. Questo elenco potrebbe
rappresentare l'intero sistema oppure un sottoinsieme.
Una vista fornisce l'accesso ad una serie di file contenuti nel repository del progetto. Inoltre, una vista fornisce
l'accesso ad un insieme appropriato di versioni di tali file:
-
E' possibile che una nuova vista di sviluppo fornisca l'accesso alla maggior parte delle versioni più recenti dei
file.
-
E' possibile che un'altra nuova vista di sviluppo fornisca l'accesso alle versioni utilizzate da un team che lavora
su una nuova interfaccia utente per il prodotto.
-
Una vista di manutenzione potrebbe fornire l'acceso alle versioni dei file utilizzati per creare un dato rilascio
del prodotto.
Uno spazio di lavoro, qualche volta denominato anche vista, consente agli sviluppatori di eseguire e verificare le
modifiche in provato prima di condividerle con il resto del team. Esistono due tipi di viste:
-
Viste istantanee
-
Viste dinamiche
Una vista istantanea fornisce allo sviluppatore un ambiente di lavoro non modificabile, stabile. E' analogo ad
un albero di directory del computer. Una vista istantanea viene popolata con le copie delle versioni appropriate dei
file contenuti in uno o più repository del progetto. Per indicare una struttura ad albero di directory talvolta viene
utilizzato il termine "sandbox". Quando uno sviluppatore desidera visualizzare le modifiche effettuate da altri membri
del team, la vista viene aggiornata. Questo stile di lavoro viene caratterizzato come un modello pull poiché si
basa sull'effettiva esecuzione del pull nelle informazioni rilevanti, piuttosto che nell'essere immediatamente
disponibile tramite i meccanismi di aggiornamento automatico.
Una vista dinamica è una struttura di dati virtuale poiché sembra che contenga tutti i dati di sviluppo. Le
viste dinamiche non eseguono copie locali dei file, ma si basano sull'aggiornamento immediato di rete. E' possibile che
le viste dinamiche rappresentino la scelta migliore nelle situazioni seguenti:
-
Lo spazio su disco dalla parte client è limitato
-
Si desidera trarre vantaggio dalla condivisione dell'oggetto derivato
-
E' necessario che il team di sviluppo lavori con le versioni del codice più aggiornate. Questa funzione è
particolarmente utile per l'integrazione che richiede la versione più recente di tutti i software forniti.
|