L'ordine di lavoro della gestione del progetto è uno stimolo per l'esecuzione di un lavoro qualsiasi su un progetto. In
base all'ordine di lavoro fornito, i membri del team pianificheranno il loro lavoro creando elenchi di cose da fare con
le scadenze che rispettino il "contratto" descritto nell'ordine di lavoro.
La fase successiva per il ruolo di responsabile è quella di ottenere o creare i prodotti di lavoro necessari su cui
lavorare o che devono essere aggiunti al controllo sorgente.
I progetti conservano di solito le versioni controllate dei prodotti di lavoro in un repository centrale ad accesso
limitato. Check-In e Check-Out solo le operazioni che consentono agli addetti allo sviluppo di ottenere una particolare
versione di un prodotto di lavoro, eseguire modifiche su di essa e reinviarla per divenire l'ultima versione
controllata. L'obiettivo di questa fase è di assicurare che gli sviluppatori seguano le procedure 'check-in e
check-out' nell'effettuare le modifiche alle versioni controllare dei prodotti di lavoro.
Le operazioni di CM principali eseguite da qualsiasi membro dello staff di sviluppo sono:
-
Check Out: concede il permesso di modificare un
elemento
-
Check in: memorizza una nuova versione dell'elemento
modificato e rende le modifiche disponibili per il check out di altri membri del team. Una regola consigliata è
quella che ogni check-in venga accompagnato da un breve commento che descrive la modifica.
-
Aggiunta al controllo sorgente: colloca un nuovo file o directory al controllo di versione, creando la
versione iniziale
-
Distribuzione: invia le modifiche all'integratore.
-
Ridefinizione: rende visibili le modifiche di altri sviluppatori.
Un implementatore lavora di solito nel seguente modo:
-
esegue il check out dei file da modificare.
-
Effettua le modifiche.
-
Esegue test di unità per verificare le modifiche.
-
Rende le modifiche approvate.
-
Esegue il check in delle modifiche.
-
Promuove le modifiche.
Diversi tipi di check out
Per default, il check out di un elemento concede il diritto esclusivo di crearne una nuova versione. Questa attività
viene definita check out riservato. Non è concesso a un altro utente di eseguire un check out riservato di
quell'elemento.
Nelle situazioni di sviluppo parallelo, il check out non riservato è un meccanismo per eseguire il check out di
un file anche se altri lo hanno già eseguito.
Alcune organizzazioni utilizzano ripetutamente lo stile di sviluppo first-come/first-served (primo arrivato/primo
servito), in cui più utenti eseguono un check out non riservato dello stesso elemento. Chiunque di loro può eseguire
successivamente un check in, per creare la successiva versione di quel file. Tutti gli altri devono fondere tali
modifiche con le modifiche precedentemente sottoposte a check in prima di creare una successiva versione.
|