Esecuzione del branching strategico

Il codice sorgente è una risorsa importante nel lavoro di sviluppo.Una gestione e un'elaborazione efficaci dei file di origine, tuttavia, può rappresentare una sfida impegnativa quando più sviluppatori si occupano simultaneamente degli aggiornamenti dei file.È possibile utilizzare un sistema di controllo della versione per archiviare codice sorgente in repository condivisi, isolare attività di sviluppo parallele, integrare modifiche al codice e recuperare versioni precedenti dei file.Un elemento chiave nel controllo della versione è la creazione di un ramo, che consente attività di sviluppo simultanee.Se si crea un ramo in modo strategico, è possibile mantenere l'ordine e la coerenza di più versioni del software.

Team Foundation fornisce un sistema di controllo della versione affidabile e flessibile.È possibile utilizzare Controllo della versione di Team Foundation per gestire più revisioni durante lo sviluppo di codice sorgente, documenti, elementi di lavoro e altre informazioni critiche utilizzate dal team. Per ulteriori informazioni sul controllo della versione in Visual Studio Team Foundation Server, vedere Utilizzo del controllo della versione.

Come gestire il codice quando si introducono simultaneamente più modifiche in diverse versioni del progetto

Quando si utilizza un sistema di controllo della versione, è necessario valutare come configurare una struttura di rami.È possibile creare un ramo eseguendo il mirroring del file del codice sorgente.È quindi possibile modificare il ramo senza influire sull'origine.Come illustrato dalla struttura di rami nella figura seguente, ad esempio, il ramo MAIN contiene una funzionalità completata che superato i test di integrazione, mentre il ramo DEVELOPMENT contiene il codice in fase di creazione.Quando una nuova funzionalità inclusa nel ramo DEVELOPMENT viene completata e supera i test di integrazione, è possibile promuovere il codice dal ramo DEVELOPMENT al ramo MAIN.Questo processo è denominato integrazione inversa.Al contrario, il processo di unione del codice dal ramo MAIN al ramo DEVELOPMENT è denominato integrazione in avanti.

Per ulteriori informazioni su come creare e unire rami del codice, vedere la pagina Guida alla creazione di rami in Team Foundation Server 2.0 del sito Web CodePlex (la pagina potrebbe essere in inglese).

La creazione di un ramo e l'unione comportano i principi seguenti:

1. Per ogni ramo devono essere disponibili criteri definiti su come integrare il codice nel ramo.Nella struttura di rami della figura precedente, ad esempio, è possibile assegnare un membro del team come proprietario e responsabile della gestione del ramo MAIN.Questo membro è responsabile dell'esecuzione dell'operazione iniziale di creazione di un ramo, dell'integrazione inversa delle modifiche dal ramo DEVELOPMENT al ramo MAIN e dell'integrazione in avanti delle modifiche dal ramo MAIN al ramo DEVELOPMENT.L'integrazione in avanti è importante quando il ramo MAIN integra anche modifiche da altri rami.

2. Il ramo MAIN deve contenere codice che abbia superato i test di integrazione, in modo che sia sempre pronto per il rilascio di una versione.

3. Il ramo DEVELOPMENT (o di lavoro) evolve continuamente, in quanto i membri del team archiviano periodicamente le modifiche.

4. Le etichette sono snapshot dei file presenti in un ramo in un momento specifico.

   Per ulteriori informazioni, vedere Utilizzare le etichette per eseguire uno snapshot dei file.

Team Foundation Build consente di scegliere tra diversi tipi di compilazione per i branch: manuale, continua, gestita, gestita e pianificata. È consigliabile che il branch MAIN abbia un tipo di compilazione di archiviazione gestita. Ciò significa che il ramo DEVELOPMENT deve soddisfare tutti i requisiti per il ramo MAIN prima di poter eseguire un'integrazione inversa.Il ramo DEVELOPMENT deve eseguire un tipo di compilazione continuata, in quanto il team deve essere informato il prima possibile se una nuova archiviazione influisce sul ramo DEVELOPMENT.

Frequenza con cui il team deve eseguire integrazioni inverse e in avanti

Come illustrato nella figura seguente, l'integrazione inversa e l'integrazione in avanti devono essere eseguite almeno quando si completa una storia utente.Benché ogni team possa definire in modo diverso la completezza, il completamento di una storia utente indica in genere che sono stati completati sia la funzionalità sia gli unit test corrispondenti.È possibile eseguire l'integrazione inversa nel ramo MAIN solo dopo che gli unit test abbiano verificato la stabilità del ramo DEVELOPMENT.

Se è presente più di un ramo di lavoro (DEVELOPMENT), l'integrazione in avanti in tutti i rami di lavoro deve essere eseguita non appena qualsiasi ramo viene integrato nel ramo MAIN.Poiché il ramo MAIN viene mantenuto stabile, l'integrazione in avanti è un'operazione sicura.Possono verificarsi conflitti o errori nei rami di lavoro perché non è possibile garantire la stabilità dei rami di lavoro.

È importante risolvere tutti i conflitti prima possibile.L'utilizzo di un'archiviazione gestita per il ramo MAIN consente di semplificare significativamente l'integrazione inversa, in quanto i controlli di qualità consentono di evitare conflitti o errori nel ramo MAIN.Per ulteriori informazioni, vedere Archiviare in una cartella controllata da un processo di compilazione di archiviazione gestita.

Modalità di gestione delle origini che implementano storie utente diverse da parte del team

Come illustrato nella figura seguente, è possibile archiviare periodicamente le modifiche in un ramo di lavoro per completare una storia utente.È possibile implementare contemporaneamente più storie utente nello stesso ramo.È tuttavia possibile eseguire l'integrazione inversa nel ramo MAIN solo dopo aver completato tutto il lavoro in corso.È consigliabile raggruppare le storie utente per dimensioni simili, in quanto è necessario evitare che una storia utente di grandi dimensioni blocchi l'integrazione di molte storie utente minori.È possibile suddividere i due set di storie utente in due rami.

Quando il team deve aggiungere un ramo?

È necessario creare rami nelle situazioni seguenti:

• Quando è necessario rilasciare codice in un diverso ciclo/pianificazione rispetto ai rami esistenti.

• Quando il codice necessita di criteri di creazione di rami diversi.Se si crea un nuovo ramo cui sono applicati i nuovi criteri, è possibile aggiungere valore strategico al progetto.

• Quando la funzionalità viene rilasciata a un cliente e il team prevede di apportare modifiche che non influiranno sul ciclo di versioni pianificato.

Non è necessario creare un ramo per ogni storia utente, perché ciò comporta costi di integrazione elevati.Benché semplifichi la creazione di un ramo, il sovraccarico della gestione dei rami può diventare significativo in presenza di molti rami.

In che modo il team gestisce le versioni dal punto di vista del controllo della versione?

Il team deve essere in grado di rilasciare codice alla fine di qualsiasi sprint.Utilizzando Team Foundation Server, è possibile contrassegnare un ramo per eseguire uno snapshot del codice in un momento specifico. Come illustrato nella figura seguente, è possibile contrassegnare il ramo MAIN per una versione. Ciò consente di restituire al branch il suo stato in quella fase.

Poiché può essere necessario implementare aggiornamenti sulle versioni, la creazione di un ramo per una versione consentirà al team di continuare a lavorare in modo indipendente sullo sprint successivo senza creare conflitti con le versioni future.Nella figura seguente viene illustrato un ramo contenente il codice per un aggiornamento e su cui viene eseguita un'integrazione inversa nel ramo MAIN dopo la creazione di una versione alla fine del secondo sprint.

Quando si crea un ramo per una versione, è consigliabile crearlo a partire dal ramo MAIN, che è più stabile.La creazione di un ramo per una versione a partire da un ramo di lavoro può provocare difficoltà di integrazione, in quanto la stabilità dei rami di lavoro non è garantita.