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 con ambito repository, i rami TFVC hanno come ambito percorso e non come leggero. Impostare la barra per la creazione di rami elevati e solo rami quando è necessario l'isolamento del codice o del rilascio.
Solo principale
La strategia Solo principale può essere basata su cartelle o con la cartella principale convertita in un ramo, per abilitare funzionalità di visibilità aggiuntive. Le modifiche vengono confermate nel ramo principale e, facoltativamente, indicano le attività cardine di sviluppo e rilascio con etichette.
RISCHIO: la mutabilità e la mancanza di cronologia con le etichette TFVC possono aggiungere il rischio di controllo delle modifiche.
Iniziare con l'unica strategia di diramazione principale, diramare strategicamente e adottare altre strategie per evolversi in strategie più complesse in base alle esigenze.
Isolamento dello sviluppo
Quando è necessario gestire e proteggere un ramo principale 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 ci siano modifiche nel ramo principale . Eseguire sempre l'integrazione principale (FI) al ramo di sviluppo e risolvere i conflitti di merge. Quindi l'integrazione inversa (RI) torna a main. Mantenere la stessa barra di qualità tra i rami. Compilare ed eseguire test di verifica della compilazione (BVT) nello stesso modo in cui si esegue il test principale.
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 di funzionalità dal ramo 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 main può essere costoso e può reimpostare i test.
Isolamento versione
L'isolamento della versione introduce uno o più rami di rilascio dal main. 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 inoltrare mai l'integrazione (FI) dal main. Bloccare i rami di rilascio usando le autorizzazioni di accesso, per evitare modifiche impreviste a una versione. Le patch e le correzioni ad accesso frequente apportate al ramo di rilascio possono essere reinvertite (RI) nel ramo principale .
NOTA: nessuno degli scenari di diramazione non è modificabile, motivo per cui si notino gli hotfix di emergenza eseguiti nei rami di rilascio. Evolvere ogni strategia in base ai propri requisiti, senza perdere la complessità e i costi associati.
Isolamento della manutenzione e del rilascio
La strategia di manutenzione e isolamento del rilascio introduce i rami di manutenzione. 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, l'isolamento della manutenzione e i rami di rilascio vengono creati quando la versione è pronta per essere bloccata. Non inoltrare mai l'integrazione da main a servicing o dalla manutenzione al rilascio. Bloccare il ramo di rilascio per impedire modifiche. Le modifiche di manutenzione future possono essere apportate nel ramo di manutenzione.
Creare nuovi rami di manutenzione e di rilascio per le versioni successive, se è necessario tale livello di isolamento.
Manutenzione, hotfix, isolamento del rilascio
Sebbene non sia consigliabile, è possibile continuare a evolvere le strategie introducendo rami hotfix aggiuntivi 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 attivazione/disattivazione delle funzionalità, 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 mantenuti il minor possibile.
Perché solo ramo, se necessario?
Per adottare DevOps, è necessario basarsi sull'automazione della compilazione, del test e della distribuzione. La modifica è continua, frequente e più complessa perché i conflitti di unione richiedono spesso 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 ripristinare le modifiche nel modo più presto possibile, per ridurre le conseguenze di merge 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 si sente come una copia dall'era 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 unisce lo sviluppo al ramo main , perché non vengono rilevate modifiche?
È probabile che siano state ignorate le modifiche nelle unioni precedenti, ad esempio usando l'opzione di risoluzione dei keep source conflitti. 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 del ramo di isolamento delle funzionalità TFVC è simile ai rami dell'argomento 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 sono riservati. Questo documento viene fornito "così come è". Le informazioni e le visualizzazioni espresse in questo documento, inclusi URL e altri riferimenti al sito Web Internet, possono cambiare senza preavviso. L'utente si assume tutti i rischi derivanti dal suo utilizzo.
Questo documento non concede alcun diritto legale su qualsiasi proprietà intellettuale di qualsiasi prodotto Microsoft. È consentito copiare e utilizzare il presente documento solo a scopo di riferimento interno.