Ramo in modo strategico

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Il codice sorgente è un asset importante nel lavoro di sviluppo. Tuttavia, può trattarsi di una sfida per gestire ed evolvere in modo efficace i file di origine quando più sviluppatori lavorano contemporaneamente sugli aggiornamenti dei file. È possibile usare un sistema di controllo della versione per archiviare il codice sorgente nei repository condivisi, per isolare le attività di sviluppo parallele, integrare le modifiche al codice e ripristinare le versioni precedenti dei file. Un elemento chiave nel controllo della versione è la diramazione che consente lo sviluppo simultaneo. Se si dirama in modo strategico, è possibile mantenere l'ordine e la coerenza di più versioni del software.

Team Foundation offre un sistema di controllo della versione flessibile e affidabile. È possibile usare il controllo della versione di Team Foundation per gestire più revisioni durante lo sviluppo di codice sorgente, documenti, elementi di lavoro e altre informazioni critiche eseguite dal team.

In che modo il team gestisce il codice mentre introduce più modifiche contemporaneamente tramite diverse versioni del progetto?

Quando si usa un sistema di controllo della versione, è necessario considerare come configurare una struttura di rami. È possibile creare un ramo eseguendo il mirroring del file di codice sorgente. È quindi possibile modificare il ramo senza influire sull'origine. Ad esempio, come illustrato nella struttura di ramo nella figura seguente, il ramo MAIN contiene funzionalità completate che hanno superato i test di integrazione e il ramo DEVELOPMENT contiene il codice in fase di costruzione. Quando viene completata una nuova funzionalità nel ramo DEVELOPMENT e può superare i test di integrazione, è possibile alzare di livello il codice dal ramo DEVELOPMENT al ramo MAIN. Questo processo viene definito integrazione inversa. Viceversa, se si unisce il codice dal ramo MAIN al ramo DEVELOPMENT, il processo viene definito integrazione in avanti.

Per altre informazioni su come creare e unire rami di codice, vedere la pagina seguente nel sito Web CodePlex: Team Foundation Server Branching Guide 2.0.

La diramazione e l'unione comportano i principi seguenti:

1. Ogni ramo deve avere un criterio definito su come integrare il codice in questo ramo. Ad esempio, nella struttura di ramo dell'illustrazione precedente, è possibile assegnare un membro del team al proprietario e gestire il ramo MAIN. Questo membro è responsabile dell'esecuzione dell'operazione iniziale del ramo, dell'integrazione inversa delle modifiche dal ramo DEVELOPMENT al ramo MAIN e dell'inoltro delle modifiche dal ramo MAIN al ramo DEVELOPMENT. L'integrazione con inoltro è importante quando il ramo MAIN integra anche le modifiche da altri rami.

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

3. Il ramo DEVELOPMENT (o work) si evolve costantemente perché i membri del team controllano periodicamente le modifiche.

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

   Per altre informazioni, vedere Usare le etichette per creare uno snapshot dei file.

Team Foundation Build consente di scegliere tra diversi tipi di compilazioni per i rami: manuale, continuo, gestito, in sequenza e pianificato. È consigliabile che il ramo MAIN abbia un tipo di compilazione di archiviazione controllato. Ciò significa che il ramo DEVELOPMENT deve superare tutti i requisiti per il ramo MAIN prima di poter eseguire il commit di un'integrazione inversa. Il ramo DEVELOPMENT deve eseguire un tipo di compilazione continuo perché il team deve conoscere il prima possibile quando un nuovo check-in influisce sul ramo DEVELOPMENT.

Con quale frequenza il team deve integrare e inoltrare l'integrazione?

Come illustrato nella figura seguente, l'integrazione inversa e l'integrazione in avanti devono verificarsi almeno quando si completa una storia utente. Anche se ogni team può definire completezza in modo diverso, il completamento di una storia utente in genere significa che si completano sia la funzionalità che gli unit test corrispondenti. È possibile invertire l'integrazione nel ramo MAIN solo dopo che gli unit test hanno verificato la stabilità del ramo DEVELOPMENT.

Se si dispone di più rami di lavoro (DEVELOPMENT), l'integrazione in avanti a tutti i rami di lavoro deve essere eseguita non appena qualsiasi ramo si integra nel ramo MAIN. Poiché il ramo MAIN è mantenuto stabile, l'integrazione forward è sicura. I conflitti o gli errori nei rami di lavoro potrebbero verificarsi perché non è possibile garantire che i rami di lavoro siano stabili.

È importante risolvere tutti i conflitti il prima possibile. Usando un check-in controllato per il ramo MAIN, è possibile semplificare notevolmente l'integrazione inversa perché i controlli di qualità consentono di evitare conflitti o errori nel ramo MAIN. Per altre informazioni, vedere Archiviare una cartella controllata da un processo di compilazione di archiviazione controllato.

In che modo il team gestisce le origini che implementano storie utente diverse?

Come illustrato nella figura seguente, è possibile archiviare periodicamente le modifiche apportate a un ramo di lavoro per completare una storia utente. È possibile implementare più storie utente nello stesso ramo contemporaneamente. Tuttavia, è possibile invertire l'integrazione al ramo MAIN solo quando si completa tutto il lavoro in corso. È consigliabile raggruppare le storie utente con dimensioni simili perché non si vuole che una storia utente di grandi dimensioni blocchi l'integrazione di molti piccoli. È possibile suddividere i due set di storie utente in due rami.

Quando il team deve aggiungere un ramo?

È consigliabile creare rami nelle situazioni seguenti:

• Quando è necessario rilasciare il codice in base a una pianificazione/ciclo diverso rispetto ai rami esistenti.

• Quando il codice richiede criteri di ramo diversi. Se si crea un nuovo ramo con 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 influiscono sul ciclo di rilascio pianificato.

Non è consigliabile creare una diramazione per ogni storia utente perché crea un costo di integrazione elevato. Anche se tfvc semplifica la diramazione, il sovraccarico della gestione dei rami può diventare significativo se si dispone 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 il codice alla fine di qualsiasi sprint. Usando Team Foundation Server , è possibile assegnare un'etichetta a un ramo per creare uno snapshot del codice in un momento specifico. Come illustrato nella figura seguente, è possibile etichettare il ramo MAIN per una versione. In questo modo è possibile restituire il ramo al relativo stato a questo punto.

Poiché è necessario implementare gli aggiornamenti nelle versioni, la creazione di un ramo per una versione consente al team di continuare a lavorare in modo indipendente nello sprint successivo senza creare conflitti con le versioni future. La figura seguente mostra un ramo che contiene il codice per un aggiornamento e che è integrato inverso nel ramo MAIN dopo una versione alla fine del secondo sprint.

Quando si crea un ramo per una versione, è necessario creare tale ramo dal ramo MAIN, che è il più stabile. Se si esegue il ramo per il rilascio da un ramo di lavoro, può causare problemi di integrazione perché la stabilità dei rami di lavoro non è garantita.

Articoli correlati

• Selezionare una strategia di diramazione efficace