Strategické větvení

 

Publikováno: duben 2016

Zdrojový kód je důležitým prostředkem v úsilí vývoje. Ale může se také výzvy pro efektivní správu a v případě, že více vývojářů pracovat současně na aktualizace souborů vyvíjet zdrojové soubory. Systém správy verzí slouží k uložení zdrojového kódu v sdílené úložiště, chcete-li zjistit paralelní vývoj úsilí, chcete-li integrovat změny kódu a obnovit předchozí verze souboru. Element v nástroji správy verzí a klíče je větvení umožňující souběžných vývoje. Je-li větví strategicky můžete udržovat pořadí a konzistenci více verzí softwaru.

Team Foundation poskytuje systému správy verzí flexibilní a spolehlivosti. Můžete použít Team Foundation – správa verzí ke správě více revize během vývoje zdrojového kódu, dokumenty, pracovních položek a dalších důležitých informací, fungující na váš tým. Další informace o správy verzí Visual Studio Team Foundation Server, naleznete v části Používání správy verzí.

Jak váš tým spravovat kódu při zavádí více změn současně prostřednictvím několika verzí projektu?

Při práci s systém správy verzí, je třeba zvážit, jak lze nastavit strukturu větev. Můžete vytvořit větvení pomocí zrcadlení soubor zdrojového kódu. Poté můžete změnit pobočky bez dopadu zdroj. Jak ukazuje strukturu větev na následujícím obrázku, hlavní větev obsahuje dokončené funkce, které již uplynulo testů integrace a vývoj větev obsahuje kód, který je vytvářena. Po dokončení nové funkce v větev vývoj a můžete předat testů integrace, můžete převést kód z vývoje větev na hlavní větev. Tento proces je označován jako reverzní integrace. Naopak je-li sloučení kódu z hlavní větve do větve vývoj proces se nazývá vpřed integrace.

Další informace o tom, jak vytvořit a sloučit kód pro větvení, získáte na následující stránce na webu CodePlex: Team Foundation Server větvení Průvodce 2.0.

Větvení a slučování za následek následující zásady:

1. Každá větev musí mít definované zásady o tom, jak integrovat do této větve kódu. Můžete například ve struktuře větvení v předchozím příkladu můžete přiřadit člen týmu na vlastní a spravují hlavní větev. Tento člen je zodpovědná za provádění operace počáteční větvení, zpětná integrace změny z vývoje větve hlavní větvení a předat dál integrace změny z větve hlavní větev vývoj. Dopředně integrace je důležité, pokud hlavní větev je integrován změny od ostatních poboček.

2. Hlavní větev musí obsahovat kód, který úspěšně prošel testů integrace, tak, aby vždy je připraven k verzi.

3. VÝVOJ (nebo práce) větev neustále vývoj, protože členové týmu vrátit se změnami pravidelně.

4. Popisky jsou snímky nebude možné soubory v větvení v určitou dobu.

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

Team Foundation Build Umožňuje zvolit z několika typů sestavení pro větvích: ruční, průběžné, ověřovaným, postupné a naplánované. Doporučujeme, aby hlavní větev má typ ověřovaným vrácení se změnami sestavení. To znamená, že větev vývoj musí uplynout mezi všechny požadavky pro větev hlavní nepotvrdíte reverzní integrace. Větev vývoj měly být spuštěny průběžně sestavení typu vzhledem k tomu, že váš tým musí znát co nejdříve při nové vrácení se změnami ovlivňuje vývoj větev.

Jak často má váš tým reverzní integrovat a předat dál integrovat?

Jak je znázorněno na následujícím obrázku, by mělo dojít k reverzní integrace a vpřed integrace alespoň při dokončení příběhu uživatele. Přestože každý tým může definovat úplnost odlišně, dokončení příběhu uživatele obecně znamená dokončení funkce a odpovídající testování částí. Můžete obrátit integrovat do větve hlavní až po ověření stabilitu větev vývoj, testování částí.

Pokud máte více než jednu větev práce (vývoj), vpřed integrace na všechny pracovní větve by mělo dojít k jako žádnou větev integruje do hlavní větev. Vzhledem k tomu, že hlavní větev je udržováno stabilní, je bezpečné vpřed integrace. Chyby v pobočkách pracovní nebo je v konfliktu mohou být způsobeny tím nemůže zaručit, aby pracovní větve jsou stabilní.

Je důležité, co nejdříve vyřešit všechny konflikty. Pomocí gated vrácení se změnami pro větev hlavní pomoci, jednodušší reverzní integrace vzhledem k tomu, že kvalitu brány vyhnout konfliktu nebo chyby v HLAVNÍM větev. Další informace naleznete v tématu Vrácení se změnami do složky, která je řízena procesem sestavení na základě hlídaného vrácení se změnami.

Jak váš tým spravovat zdroje, které implementují scénáře jiného uživatele?

Jak ukazuje na následujícím obrázku, můžete zkontrolovat v se změní na pracovní větev pravidelně k dokončení příběhu uživatele. Současně lze implementovat několika příběhy uživatelů ve stejné pobočce. Můžete však obrátit integrovat do větve hlavní pouze v případě, že jste dokončili veškeré probíhající práce. Je vhodné seskupit scénáře uživatelů podle podobné velikosti, protože nechcete, aby příběhu velké uživatele blokovat integraci mnoho malých sítí. Rozdělit dvou sad scénáře uživatelů na dvě větve.

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

Měli byste vytvořit větvení v následujících situacích:

• Pokud je nutné uvolnit kód na různých plán/cyklu než existující větve.

• Pokud je váš kód vyžaduje jiný větev zásad. Pokud vytvoříte novou větev, která obsahuje novou zásadu, budou hodnotu můžete přidat do svého projektu.

• Funkce uvolnění zákazníkovi, a váš tým plány provádět změny, které nemají vliv na cyklus plánované vydání.

Neměli byste vytvářet větvení pro každý text uživatele protože vytváří vysoké integrace náklady. Přestože Team Foundation Server umožňuje snadné větvení, se může stát významné, pokud máte více pobočkami nároky na výkon správa poboček.

Jak týmu spravovat vydání z hlediska řízení verzí?

Váš tým by měla být uvolnit kód na konci jakékoli sprint. S použitím Team Foundation Server, můžete označit popiskem větvení pořizování snímku kódu v určitém místě v čase. Jak ukazuje na následujícím obrázku, můžete označit popiskem větev hlavní verze. To umožňuje vrátit větev do stavu v tomto bodě.

Vzhledem k tomu, že je nutné implementovat aktualizace na vydání, vytváření větvení verze pomáhá vašemu týmu, i nadále pracovat nezávisle na další sprint bez vytvoření je v konfliktu s budoucích verzích. Následující obrázek ukazuje, že větvení, který obsahuje kód pro aktualizaci a který je zpětně integrovány do hlavní větev po vydání na konci druhý sprint.

Po vytvoření větve verze, měli byste vytvořit takové pobočky z hlavní větve, který je nejvíce stabilní. Pokud jste větví k uvolnění z pracovní větvení, může způsobit integrace výzvy vzhledem k tomu, že není zaručena stabilitu pracovní poboček.