Selezionare una strategia di diramazione efficace
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
La creazione di rami per i repository di Controllo della versione di Team Foundation (TFVC) è utile per isolare i rischi. Considerare alcune sfide che i membri del team affrontano in genere quando lavorano su un progetto software che viene gestito da più di cinque o dieci persone:
Il gruppo ha alcuni (o forse diversi) team di funzionalità diversi, ognuno dei quali lavora su un set di funzionalità ragionevolmente discreto. Ma ogni team dipende anche dalle funzionalità create da altri team. È necessario isolare il rischio delle modifiche introdotte dal lavoro svolto in ognuno di questi team, ma alla fine, è necessario unire tutti i loro sforzi insieme in un unico prodotto.
Il team di test necessita di una versione stabile del codice da testare e, tuttavia, contemporaneamente, gli sviluppatori devono continuare a proseguire con nuove funzionalità che occasionalmente destabilizzano il prodotto.
Il software ha due versioni precedenti e una versione corrente in corso. Anche se la maggior parte delle attività di sviluppo è investita nella versione corrente, le versioni precedenti devono comunque essere supportate con versioni occasionali di Service Pack, correzioni critiche e patch di sicurezza e altre modifiche.
Questo articolo illustra alcune strategie comuni di diramazione che consentono di prendere la decisione giusta.
A differenza dei rami Git, che sono a livello di repository, i rami TFVC sono a livello di percorso e non sono così leggeri. Fissa standard elevati per la creazione di rami e diramare solo quando è necessario l'isolamento del codice o del rilascio.
Solo principale
La strategia principale solo può essere basata su cartelle o con la cartella principale convertita in un ramoper abilitare funzionalità di visibilità aggiuntive. Conferisci le tue modifiche al ramo principale e, facoltativamente, indichi i traguardi di sviluppo e rilascio con le etichette.
RISCHIO: la mutabilità e la mancanza di cronologia con le etichette TFVC possono aggiungere il rischio di controllo delle modifiche.
Inizia con la strategia principale di ramificazione, ramifica strategicamente e adotta altre strategie per evolvere in strategie più complesse in base alle esigenze.
Isolamento dello sviluppo
Quando è necessario mantenere e proteggere un ramo principale di stabile, è possibile creare uno o più rami di sviluppo dal ramo principale . Consente l'isolamento e lo sviluppo simultaneo. Il lavoro può essere isolato nei rami di sviluppo in base a funzionalità, organizzazione o collaborazione temporanea.
È possibile che siano presenti modifiche nel ramo principale. Eseguire sempre l'integrazione diretta (FI) al ramo principale e al ramo di sviluppo , e risolvere i conflitti di unione. Quindi l'integrazione inversa (RI) torna a principale. Mantenere lo stesso standard di qualità tra i settori. Compilare ed eseguire test di verifica della build (BVT) su dev allo stesso modo in cui si compilano ed eseguono su main.
NOTA: con questa strategia, è probabile che i team mantengano il ramo di sviluppo per sempre, creando potenzialmente una cronologia di ticket di merge di grandi dimensioni.
Isolamento delle funzionalità
L'isolamento delle funzionalità è una derivazione speciale dell'isolamento dello sviluppo, che consente di diramare uno o più rami funzionalità da principale, come illustrato o dai rami di sviluppo .
Quando è necessario lavorare su una particolare funzionalità, potrebbe essere consigliabile creare un ramo di funzionalità.
Mantenere la durata del lavoro delle funzionalità e il ramo di funzionalità associato di breve durata. Inoltrare frequentemente le modifiche di integrazione (FI) dal ramo padre. L'integrazione inversa (RI) all'elemento padre solo quando vengono soddisfatti alcuni criteri del team concordati, ad esempio la definizione di fatto. Il rollback delle funzionalità in principale può essere costoso e può reimpostare i test.
Rilascio isolamento
L'isolamento del rilascio introduce uno o più rami di versione dalla principale. La strategia consente la gestione simultanea delle versioni, più versioni parallele e snapshot della codebase in fase di rilascio.
Quando la versione è pronta per essere bloccata, è possibile creare un nuovo ramo per la versione.
Non effettuare mai l'integrazione diretta (FI) da principale. Bloccare i rami di rilascio usando le autorizzazioni di accesso, per impedire modifiche indesiderate a una versione . Le patch e gli hotfix apportati al ramo della versione possono essere integrati inversamente nel ramo principale .
NOTA: Nessuno degli scenari di diramazione è immutabile, motivo per cui si notano gli hotfix di emergenza effettuati nei rami di rilascio. Evolvere ogni strategia in base ai propri requisiti, senza perdere la complessità e i costi associati.
Isolamento per la manutenzione e il rilascio
La strategia di isolamento per la gestione e il rilascio introduce rami di gestione. Questa strategia consente la gestione simultanea dei Service Pack e degli snapshot codebase in fase di rilascio.
Usare questa strategia se è necessario un modello di manutenzione per i clienti per eseguire l'aggiornamento alla versione principale successiva e ai Service Pack aggiuntivi per ogni versione.
Analogamente all'isolamento della versione, i rami di manutenzione e rilascio vengono creati quando la versione è pronta per essere bloccata. Non eseguire mai l'integrazione da principale a manutenzioneo da di manutenzione a versione. Bloccare il ramo versione per impedire modifiche. È possibile apportare modifiche future alla manutenzione sul ramo di manutenzione .
Creare nuovi rami di manutenzione e di rilascio per le versioni successive, se è necessario tale livello di isolamento.
Manutenzione, correzione rapida, isolamento del rilascio
Sebbene non sia consigliabile, è possibile continuare a evolvere le strategie introducendo altri hotfix rami e scenari di rilascio associati.
A questo punto, sono stati esaminati correttamente alcuni degli scenari comuni di diramazione TFVC. È possibile evolverli o analizzare altre strategie, ad esempio funzionalità di attivazione/disattivazione, attivazione e disattivazione delle funzionalità per determinare se una funzionalità è disponibile in fase di esecuzione.
Domande e risposte
Perché i rami devono essere di breve durata?
Mantenendo i rami di breve durata, i conflitti di merge vengono ridotti al minimo.
Perché solo ramo, se necessario?
Per adottare DevOps, è necessario basarsi sull'automazione della compilazione, del test e della distribuzione. Il cambiamento è continuo, frequente, e rende le operazioni di merge più complesse poiché spesso i conflitti di merge richiedono un intervento manuale. È quindi consigliabile evitare la diramazione e fare affidamento su altre strategie, ad esempio l'attivazione/disattivazione delle funzionalità.
Perché rimuovere i rami?
L'obiettivo dovrebbe essere quello di riportare le modifiche in principale il prima possibile, per attenuare le conseguenze dell'unione a lungo termine. I rami temporanei, inutilizzati e abbondanti causano confusione e sovraccarico per il team.
Una codebase può essere diramata tra progetti?
Sì. Non è consigliabile, a meno che i team non debbano condividere l'origine e non possano condividere un processo comune.
Che ne dici della strategia di promozione del codice?
La strategia di promozione del codice sembra un relitto dall'epoca dello sviluppo a cascata. Si tratta in genere di cicli di test lunghi e di team di sviluppo e test separati. La strategia non è più consigliata. Per altre informazioni su questa strategia, vedere le linee guida per la diramazione .
Quando si fonde il ramo di sviluppo al ramo principale , perché non vengono rilevate modifiche?
È probabile che siano state ignorate le modifiche apportate alle unioni precedenti, ad esempio usando l'opzione di risoluzione dei conflitti keep source. Per informazioni dettagliate, vedere merge del ramo di sviluppo a main: non sono state apportate modifiche al merge.
Esistono analogie tra le strategie del ramo TFVC e Git?
La strategia di diramazione per l'isolamento delle funzionalità di TFVC è simile ai rami tematici di Git .
Autori: Jesse Houwing, Marcus Fdevice, Mike Fourie e Willy Schaub dell'ALM | DevOps Rangers. È possibile contattarli qui.
(c) 2015 Microsoft Corporation. Tutti i diritti riservati. Questo documento viene fornito "as-is". Le informazioni e le opinioni espresse in questo documento, inclusi URL e altri riferimenti a siti Web Internet, possono cambiare senza preavviso. L'utente si assume tutti i rischi derivanti dal loro utilizzo.
Questo documento non fornisce diritti legali a alcuna proprietà intellettuale in alcun prodotto Microsoft. È consentito copiare e utilizzare il presente documento solo a scopo di riferimento interno.