Výběr efektivní strategie větvení

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Vytváření větví pro úložiště Správa verzí Team Foundation (TFVC) je užitečné izolovat rizika. Při práci na softwarovém projektu, který je obsazený více než pěti nebo deseti lidmi, zvažte některé výzvy, kterým obvykle čelí členové týmu:

• Skupina má několik (nebo možná několik) různých týmů funkcí, přičemž každá pracuje na sadě funkcí, která je přiměřeně diskrétní. Každý tým ale také závisí na funkcích vytvořených jinými týmy. Potřebujete izolovat riziko změn zavedených prací v každém z těchto týmů, a přesto nakonec musíte všechny jejich úsilí sloučit do jednoho produktu.

• Testovací tým potřebuje stabilní verzi kódu k testování, a přesto současně musí vývojáři pokračovat v dalším pohybu s novými funkcemi, které občas budou produkt stabilizovat.

• Software má dvě předchozí verze a jednu aktuální verzi. I když je většina úsilí o vývoj investována do aktuální verze, musí být předchozí verze stále podporovány s občasnými verzemi aktualizací Service Pack, kritickými opravami a opravami zabezpečení a dalšími změnami.

Tento článek popisuje několik běžných strategií větvení, které vám pomůžou se správným rozhodnutím.

Na rozdíl od větví Gitu, které jsou omezené na úložiště, jsou větve TFVC vymezeny cestou a ne tak odlehčené. Nastavte panel pro vytváření větví s vysokou úrovní a jenom v případě, že potřebujete izolaci kódu nebo vydané verze.

Pouze hlavní

Strategie Pouze hlavní může být založená na složkách nebo s hlavní složkou převedenou na větev, aby bylo možné povolit další funkce viditelnosti. Změny potvrdíte v hlavní větvi a volitelně označíte milníky vývoje a vydání s popisky.

RIZIKO: Proměnlivost a nedostatek historie popisků TFVC může přidat riziko kontroly změn.

Začněte hlavní strategií větvení, strategicky větvete a přijměte další strategie, aby se podle potřeby vyvinuly do složitějších strategií.

Izolace vývoje

Pokud potřebujete udržovat a chránit stabilní hlavní větev, můžete větev jedné nebo více vývojových větví z hlavní větve. Umožňuje izolaci a souběžný vývoj. Práci je možné izolovat ve vývojových větvích podle funkce, organizace nebo dočasné spolupráce.

Je možné, že v hlavní větvi došlo ke změnám. Vždy předávat hlavní integraci (FI) do vývojové větve a řešit konflikty při slučování. Pak se změny zpětné integrace (RI) vrátí zpět na hlavní. Udržujte stejný panel kvality napříč větvemi. Sestavte a spusťte ověřovací testy sestavení (BVT) pro vývoj stejným způsobem, jakým provádíte hlavní úlohy.

POZNÁMKA: Díky této strategii budou týmy pravděpodobně udržovat vývojovou větev napořád a potenciálně vytvářet velkou historii lístků hromadné korespondence.

Izolace funkcí

Izolace funkcí je speciální odvození izolace vývoje, která umožňuje větvet jednu nebo více větví funkcí z hlavní větve, jak je znázorněno, nebo z vývojových větví.

Když potřebujete pracovat na konkrétní funkci, může být vhodné vytvořit větev funkcí.

Udržujte životnost funkce a přidruženou větev funkcí krátkodobě. Předávat změny integrace (FI) z nadřazené větve často. Zpětná integrace (RI) zpět do nadřazeného objektu pouze v případě, že jsou splněna některá dohodnutá kritéria týmu, například definice hotovo. Vrácení funkcí na hlavní straně může být nákladné a může resetovat testování.

Izolace vydaných verzí

Izolace vydané verze zavádí jednu nebo více větví vydaných verzí z hlavní větve. Strategie umožňuje souběžnou správu verzí, několik paralelních verzí a snímky základu kódu v době vydání.

Až bude verze připravená k uzamčení, je čas vytvořit novou větev pro vydání.

Nikdy nepřeposílat integraci (FI) z main. Uzamkněte větve vydaných verzí pomocí přístupových oprávnění, abyste zabránili nezamýšleným změnám vydané verze. Opravy a opravy za chodu provedené ve větvi vydané verze můžou být zpětně integrované (RI) zpět do hlavní větve.

POZNÁMKA: Žádný ze scénářů větvení není neměnný, což je důvod, proč si všimnete tísňových oprav hotfix provedených ve větvích vydaných verzí. Vyvíjet každou strategii tak, aby odpovídala vašim požadavkům, aniž byste ztratili přehled o složitosti a souvisejících nákladech.

Izolace údržby a vydávání verzí

Strategie izolace údržby a vydávání verzí zavádí servisní větve. Tato strategie umožňuje souběžnou správu aktualizací Service Pack a snímků základu kódu v době vydání.

Tuto strategii použijte, pokud potřebujete servisní model pro zákazníky k upgradu na další hlavní verzi a další aktualizace Service Pack na jednotlivé verze.

Stejně jako izolace vydané verze se vytvoří servisní izolace a větve vydaných verzí, když je verze připravená k uzamčení. Nikdy nepředávejte integraci z hlavního do servisního nebo servisního do vydání. Zamknutím větve vydané verze zabráníte úpravám. Budoucí změny údržby je možné provádět ve větvi údržby.

Pokud potřebujete tuto úroveň izolace, vytvořte nové větve údržby a vydaných verzí pro následné verze.

Údržba, oprava hotfix, izolace vydaných verzí

I když se nedoporučuje, můžete i nadále vyvíjet strategie tím, že zavádíte další větve oprav hotfix a přidružené scénáře vydání.

V tomto okamžiku jste úspěšně prozkoumali několik běžných scénářů větvení TFVC. Můžete je vyvíjet nebo zkoumat jiné strategie, jako je přepínání funkcí, zapnutí nebo vypnutí funkcí, abyste zjistili, jestli je funkce dostupná za běhu.

Q&A

Proč by měly být větve krátkodobé?

Udržováním krátkodobých větví se konflikty při slučování uchovávají co nejméně.

Proč větev jenom v případě potřeby?

Pokud chcete využít DevOps, musíte se spolehnout na automatizaci sestavení, testování a nasazení. Změny jsou průběžné, časté a slučovací operace náročnější, protože konflikty při slučování často vyžadují ruční zásah. Proto se doporučuje vyhnout větvení a spoléhat se na jiné strategie, jako je přepínání funkcí.

Proč odebrat větve?

Vaším cílem by mělo být co nejdříve vrátit změny zpět do hlavního systému, aby se zmírňovaly dlouhodobé důsledky sloučení. Dočasné, nepoužité a bohaté větve způsobují nejasnosti a režijní náklady pro tým.

Je možné rozvětvení základu kódu napříč projekty?

Ano. Nedoporučuje se, pokud týmy nesmí sdílet zdroj a nemohou sdílet společný proces.

A co strategie povýšení kódu?

Strategie povýšení kódu se cítí jako relikt z vodopádové vývojové éry. Obvykle se jedná o dlouhé testovací cykly a samostatné vývojové a testovací týmy. Strategie se už nedoporučuje. Další informace o této strategii najdete v doprovodných materiálech k větvení.

Proč se při slučování vývoje do hlavní větve nezjistí žádné změny?

Pravděpodobně jste ignorovali změny v předchozích sloučeních, například pomocí keep source možnosti řešení konfliktů. Podívejte se na sloučení vývojové větve na hlavní větev: Podrobnosti nebyly změněny .

Existují podobnosti mezi strategiemi TFVC a větví Gitu?

Strategie větvení izolace funkcí TFVC je podobná větvím tématu Gitu.

Autoři: Jesse Houwing, Marcus Fernandez, Mike Fourie a Willy Schaub z ALM | DevOps Rangers. Můžete je kontaktovat tady.

c) 2015 Microsoft Corporation. Všechna práva vyhrazena. Tento dokument je k dispozici tak, jak je. Informace a zobrazení vyjádřená v tomto dokumentu, včetně adres URL a jiných odkazů na internetové weby, se mohou bez předchozího upozornění změnit. Riziko spojené s jejich použitím nesete vy.

Tento dokument vám neposkytuje žádná zákonná práva na duševní vlastnictví, které je součástí jakéhokoli produktu společnosti Microsoft. Tento dokument můžete kopírovat a používat pro své interní referenční účely.