Normalmente, ogni membro del team esegue il proprio lavoro sul proprio workbench, indipendente dagli altri. Alla conclusione, il lavoro dovrà essere rilasciato agli altri e le modifiche di tutti i membri dovranno essere condivise. Questa operazione avviene attraverso i flussi.
I flussi sono gli elementi in cui un team condivide e integra il proprio lavoro in uscita.
Un flusso può essere considerato come un'area di lavoro condivisa che viene aggiornata dai membri del team nel momento in cui questi apportano modifiche al progetto. Questo modello consente ai singoli membri di partecipare a un progetto di team, condividere il proprio lavoro con gli altri e accedere al lavoro di altri membri mentre il progetto si evolve.
Mentre i membri del team producono il nuovo lavoro, lo condividono rilasciando nel flusso le modifiche apportate. Allo stesso modo, quando i membri desiderano ricevere l'ultimo lavoro disponibile, catturano le modifiche dal flusso. Quindi, il flusso è costantemente modificato e si evolve man mano che i membri del team rilasciano il nuovo lavoro.
Il flusso rappresenta effettivamente lo stato corrente del progetto. In qualsiasi momento un membro del team può catturare il flusso e individuare lo stato di aggiornamento del lavoro.
Modello di programmazione per team
I sistemi di controllo della versione forniscono due importanti funzioni necessarie per il lavoro in un team:
una cronologia del lavoro eseguito dal team
un sistema per coordinare e integrare tale lavoro.
La conservazione di una cronologia è importante per poter confrontare il lavoro corrente con un lavoro precedente, per poter ritornare a un lavoro precedente che risulta migliore, e così via. Il coordinamento del lavoro è fondamentale poiché esiste una definizione dello stato di progetto corrente, contenente il lavoro integrato del team. Questo coordinamento viene fornito dal modello di flusso.
Un modello ottimistico è quello in cui tutti i membri del team possono apportare modifiche a qualsiasi risorsa a cui è possibile accedere. Poiché due membri del team possono rilasciare nel flusso modifiche alla stessa risorsa, potrebbero verificarsi conflitti che dovranno essere gestiti. Questo modello viene detto ottimistico poiché si presuppone che i conflitti siano rari.
Normalmente, le risorse non sono indipendenti ma contengono, implicitamente o esplicitamente, riferimenti ad altre risorse. Ad esempio, le pagine web hanno collegamenti ad altre pagine web e il codice di origine ha riferimenti ad elementi descritti in altre risorse del codice di origine. Nessuna risorsa è quindi isolata.
Quando le risorse vengono rilasciate nel flusso, tali riferimenti possono essere influenzati. È importante assicurarsi dell'integrità delle dipendenze poiché il flusso rappresenta lo stato corrente del progetto: in qualsiasi momento, un membro del team può prendere il contenuto dei flusso e utilizzarlo come base per un nuovo lavoro.
Il flusso di lavoro ideale deve, quindi, essere caratterizzato dall'integrità del flusso.
Il flusso di lavoro ideale procede nel seguente modo:
Avvio aggiornato: prima di iniziare il lavoro, catturare lo stato del flusso corrente. Se non si dispone di lavoro locale di cui preoccuparsi eccessivamente, il modo più rapido per effettuare la cattura consiste nel selezionare dal flusso i progetti a cui si è interessati e selezionare "Aggiungi all'area di lavoro". In questo modo, tutte le risorse locali verranno sovrascritte dalle risorse prelevate dal flusso.
Esecuzione di modifiche: lavorare localmente nel proprio workbench, creare nuove risorse, modificare risorse esistenti e salvare localmente.
Sincronizzazione: quando si è pronti a rilasciare il proprio lavoro, eseguire l'operazione Sincronizza con flusso.
Cattura: esaminare le modifiche in entrata e aggiungerle al proprio workbench locale. Ciò consente di determinare l'eventuale presenza di modifiche che potrebbero influire sull'integrità delle risorse che stanno per essere rilasciate. Risoluzione dei conflitti. Effettuare una nuova verifica, eseguire checker di integrità (ad es., verificare eventuali collegamenti ipertestuali danneggiati, assicurarsi della corretta compilazione del codice, etc.).
Rilascio: quando si è certi che le modifiche verranno ben integrate nel contenuto del flusso, rilasciarle. Per prudenza, è possibile ripetere il passo 4 se esistono ancora nuove modifiche in entrata.
Naturalmente questo rappresenta un flusso di lavoro ideale. In certe condizioni, quando si ritiene che le modifiche in entrata non influenzano il proprio lavoro, si può effettuare il rilascio senza eseguire la cattura. Tuttavia, i membri del team dovrebbero cercare di seguire un flusso di lavoro simile a quello appena descritto, in modo da essere certi che l'integrità del flusso non venga accidentalmente compromessa.