Strategické větvení

Zdrojový kód je důležitým prostředkem při vývoji.Efektivně spravovat a rozvíjet zdrojové soubory ale může být při souběžné práci více vývojářů na úpravách souboru obtížné.Pro ukládání zdrojového kódu na sdílených úložištích je možné použít systém pro správu verzí pro izolování činnosti paralelního programování, pro integraci změn v kódu a pro obnovení předchozí verze souboru.Klíčovým prvkem ve správě verzí je větvení, které umožňuje simultánní vývoj.Pokud je větvení nastaveno strategicky, je možné spravovat pořadí a konzistentnost více verzí softwaru.

Team Foundation poskytuje flexibilní a spolehlivý systém správy verzí.Pro správu více revizí v průběhu vývoje zdrojového kódu, dokumentů, pracovních položek a dalších důležitých informací, na kterých pracuje tým, je možné použít Team Foundation – správa verzí.Další informace o správě verzí ve Visual Studio Team Foundation Server naleznete na Používání správy verzí.

Jakým způsobem váš tým spravuje kód při provádění několika změn současně napříč několika verzemi projektu?

Při práci se systémem správy verzí je nutné zvážit, jak nastavit strukturu větvení.Je možné vytvořit větev zrcadlením souboru zdrojového kódu.Následně je možné větev změnit bez ovlivnění zdroje.Jak tomu je například u této struktury větvení. Větev MAIN obsahuje kompletní funkcionalitu, která prošla integračními testy a větev DEVELOPMENT obsahuje kód, na kterém se pracuje.Jakmile je dokončena nová funkcionalita ve větvi DEVELOPMENT a může projít integračními testy, je možné předat kód z větve DEVELOPMENT do větve MAIN.Tento proces se nazývá zpětná integrace.Naopak pokud sloučíte kód z větve MAIN do větve DEVELOPMENT nazývá se proces dopředná integrace.

Další informace o vytvoření a sloučení kódu více větví naleznete v tématu Průvodce větvením serveru Team Foundation Server 2.0 na webu CodePlex.

Větvení a slučování se řídí následujícími zásadami:

1. Každá větev musí mít definované zásady o tom, jak integrovat do této větve kód.Například ve struktuře větvení na předchozím obrázku můžete přiřadit člena týmu jako vlastníka a správce větve MAIN.Tento člen je odpovědný za provádění počátečních operací větve, zpětnou integraci změn z větve DEVELOPMENT do větve MAIN a dopředné integrace změn z větve MAIN do větve DEVELOPMENT.Dopředná integrace je důležité ve chvíli, kdy větev MAIN integruje změny z ostatních větví.

2. Hlavní větev musí obsahovat kód, který prošel integračními testy tak, aby byla vždy připravena k vydání.

3. Větev DEVELOPMENT (nebo pracovní) se konstantně rozvíjí, protože členové týmu pravidelně vkládají změny.

4. Popisky jsou snímky souborů v rámci větve v určitém čase.

   Další informace naleznete v tématu Použití popisků k uložení aktuálního stavu souborů.

Team Foundation Build dovoluje výběr z několika typů sestavení pro větve: ruční, souvislé, ověřované, postupné a naplánované.Doporučujeme, aby větev MAIN byla typu sestavení ověřované vracení zpět.To znamená, že větev DEVELOPMENT musí projít všemi požadavky větve MAIN, před potvrzením zpětné integrace.Větev DEVELOPMENT by měla spustit typ nepřetržitého sestavení, protože tým musí co nejdříve vědět, kdy nové vložení kódu ovlivnilo větev DEVELOPMENT.

Jak často by měl tým provést zpětnou a dopřednou integraci?

Jak je znázorněno na následujícím obrázku, zpětná a dopředná integrace by měla probíhat alespoň po dokončení uživatelského scénáře.Přestože každý tým může definovat různé stupně dokončení, dokončení uživatelského scénáře znamená dokončení jak funkcionality, tak i odpovídajících jednotkových testů.Je možné provést reverzní integraci na větvi MAIN pouze po ověření stability větve DEVELOPMENT jednotkovými testy.

Pokud máte více než jednu pracovní (DEVELOPMENT) větev, měla by probíhat dopředná integrace ihned, jakmile se jakákoliv větev integruje do větve MAIN.Vzhledem k tomu, že hlavní větev je udržována stabilní, dopředná integrace je bezpečná.V pracovních větvích se mohou vyskytovat konflikty nebo chyby, jelikož nelze zaručit stabilitu pracovních větví.

Je důležité co nejdříve vyřešit všechny konflikty.Pomocí ověřeného vrácení zpět na větvi MAIN je reverzní integrace snazší, protože kvalitativní ověření napomáhají vyhnutí se konfliktům nebo chybám ve větvi MAIN.Další informace naleznete v tématu Kontrola v čekající změny, které jsou řízeny Gated změnami sestavení.

Jak tým spravuje zdroje, které implementují různé uživatelské scénáře?

Jak ukazuje následující obrázek, lze pro dokončení uživatelského scénáře do pracovní větve vracet změny pravidelně.Současně lze implementovat ve stejné větvi několik uživatelských scénářů.Avšak reverzní integraci do větve MAIN lze provést pouze po dokončení všech probíhajících položek.Je vhodné seskupit uživatelské scénáře na základě podobné velikosti, protože nechcete, aby velké uživatelské scénáře blokovaly integraci více malých scénářů.Je možné rozdělit dvě sady uživatelských scénářů do dvou větví.

Kdy by měl tým přidat větev?

Větve byste měli vytvořit v následujících situacích:

• Pokud musíte vydat kód na základě jiného plánu/cyklu než pro stávající větve.

• Pokud váš kód vyžaduje jiné zásady větvení.Pokud vytvoříte novou větev obsahující novou zásadu, můžete do projektu přidat strategickou hodnotu.

• Při vydání funkcionality zákazníkovi a při naplánování změn týmem, které provedou změny, které nemají vliv na plánovaný cyklus vydání.

Neměli byste vytvářet větev pro každý uživatelský scénář, protože to může vést k vytvoření vysokých nákladů při integraci.I když umožňuje snadné větvení, režijní náklady na správu větví se mohou stát podstatnými, pokud máte mnoho větví.

Jak může tým spravovat vydání z hlediska správy verzí?

Tým by měl být schopen vydat kód na konci jakéhokoli sprintu.Pomocí Team Foundation Server je možné označení větve pro vytvoření snímku kódu v určitém místě v čase.Jak ukazuje následující obrázek, je možné označit větev MAIN pro vydání nové verze.To umožňuje vrátit větev v daném okamžiku do jejího stavu.

Vzhledem k tomu, že je zapotřebí implementovat aktualizace při vydání nové verze, pomáhá vytvoření větvení při vydání nové verze týmu pokračovat v práci bez závislosti na příštím sprintu, aniž by byly vytvořeny konflikty v následujících vydáních nových verzí.Následující obrázek ukazuje větev obsahující kód pro aktualizaci, která je zpětně integrována do větve MAIN po vydání nové verze na konci druhého sprintu.

Po vytvoření větve pro vydání nové verze je zapotřebí, aby tato větev byla vytvořena z větve MAIN, která je nejstabilnější.Vytvoření větve pro vydání nové verze z pracovní větve může způsobit problémy při integraci, protože stabilita pracovních větví není zaručena.