Strategicky rozvětvení

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

Zdrojový kód je důležitým aktivem ve vašem úsilí o vývoj. Může to ale být výzva k efektivní správě a vývoji zdrojových souborů, když na aktualizacích souborů současně pracuje více vývojářů. Pomocí systému správy verzí můžete uložit zdrojový kód do sdílených úložišť, izolovat paralelní vývoj, integrovat změny kódu a obnovit předchozí verze souborů. Klíčovým prvkem ve správě verzí je větvení, které umožňuje souběžný vývoj. Pokud strategicky rozvětvujete, můžete udržovat pořadí a konzistenci více verzí softwaru.

Team Foundation poskytuje flexibilní a spolehlivý systém správy verzí. Správu verzí Team Foundation můžete použít ke správě více revizí při vývoji zdrojového kódu, dokumentů, pracovních položek a dalších důležitých informací, na které pracuje váš tým.

Jak váš tým spravuje kód, když současně zavádí více změn prostřednictvím několika verzí projektu?

Při práci se systémem správy verzí musíte zvážit, jak nastavit strukturu větve. Větev můžete vytvořit zrcadlením souboru zdrojového kódu. Potom můžete změnit větev bez ovlivnění zdroje. Jak například ukazuje struktura větve na následujícím obrázku, větev MAIN obsahuje dokončené funkce, které prošly integračními testy, a větev DEVELOPMENT obsahuje kód, který je součástí výstavby. Když se dokončí nová funkce ve větvi DEVELOPMENT a může projít integračními testy, můžete zvýšit úroveň kódu z větve DEVELOPMENT na větev MAIN. Tento proces se označuje jako zpětná integrace. Pokud naopak sloučíte kód z větve MAIN do větve DEVELOPMENT, označuje se proces jako dopředná integrace.

Další informace o vytváření a slučování větví kódu naleznete na následující stránce na webu CodePlex: Team Foundation Server Branching Guide 2.0.

Větvení a slučování zahrnují následující principy:

1. Každá větev musí mít definované zásady týkající se integrace kódu do této větve. Například ve struktuře větve předchozího obrázku můžete přiřadit člena týmu, který vlastní a spravuje větev MAIN. Tento člen zodpovídá za provádění počáteční operace větve, zpětnou integraci změn z větve DEVELOPMENT do větve MAIN a předávání změn z větve MAIN do větve DEVELOPMENT. Předávání integrace je důležité, když větev MAIN také integruje změny z jiných větví.

2. Větev MAIN musí obsahovat kód, který prošel testy integrace, aby byl vždy připravený na vydání.

3. Větev DEVELOPMENT (nebo pracovní) se neustále vyvíjí, protože členové týmu pravidelně kontrolují změny.

4. Popisky jsou snímky souborů ve větvi v určitém čase.

   Další informace najdete v tématu Použití popisků k pořízení snímku souborů.

Team Foundation Build umožňuje vybrat si z několika typů sestavení pro vaše větve: ruční, nepřetržitý, zaměněný, válcovaný a naplánovaný. Doporučujeme, aby větev MAIN má vrátný typ buildu vrácení se změnami. To znamená, že větev DEVELOPMENT musí před potvrzením zpětné integrace předat všechny požadavky pro větev MAIN. Větev DEVELOPMENT by měla spouštět typ průběžného sestavení, protože váš tým musí vědět co nejdříve, když nové vrácení se změnami ovlivní větev DEVELOPMENT.

Jak často by váš tým měl provést zpětnou integraci a integraci vpřed?

Jak je znázorněno na následujícím obrázku, měla by se zpětná integrace a dopředná integrace objevit alespoň po dokončení uživatelského scénáře. I když každý tým může definovat úplnost odlišně, dokončení uživatelského scénáře obecně znamená, že dokončíte funkce i odpovídající testy jednotek. Zpětnou integraci do větve MAIN můžete provést až po ověření stability větve DEVELOPMENT.

Pokud máte více než jednu pracovní větev (DEVELOPMENT), měla by se integrace předat všem pracovním větvím, jakmile se jakákoli větev integruje do větve MAIN. Vzhledem k tomu, že větev MAIN je stabilní, je integrace vpřed bezpečná. Ke konfliktům nebo selháním v pracovních větvích může dojít, protože nemůžete zaručit, že pracovní větve jsou stabilní.

Je důležité, abyste co nejdříve vyřešili všechny konflikty. Použitím zamknutého vrácení se změnami pro větev MAIN usnadníte zpětnou integraci, protože brány kvality pomáhají vyhnout se konfliktům nebo chybám ve větvi MAIN. Další informace najdete v tématu Vrácení se změnami do složky, která je řízena procesem vrácení se změnami.

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

Jak ukazuje následující obrázek, můžete pravidelně kontrolovat změny v pracovní větvi, aby bylo možné dokončit uživatelský příběh. Ve stejné větvi můžete implementovat více uživatelských scénářů najednou. Integraci do větve MAIN ale můžete vrátit zpět pouze v případě, že dokončíte veškerou probíhající práci. Doporučuje se seskupit uživatelské scénáře podle podobné velikosti, protože nechcete, aby rozsáhlý uživatelský scénář blokoval integraci mnoha malých. Tyto dvě sady uživatelských scénářů můžete rozdělit do dvou větví.

Kdy má tým přidat větev?

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

• Pokud je nutné uvolnit kód v jiném plánu nebo cyklu než existující větve.

• Pokud váš kód vyžaduje jinou zásadu větve. Pokud vytvoříte novou větev s novou zásadou, můžete do projektu přidat strategickou hodnotu.

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

Pro každý uživatelský scénář byste neměli vytvářet větvení, protože vytváří vysoké náklady na integraci. I když TFVC usnadňuje větvení, může být režie správy větví významná, pokud máte mnoho větví.

Jak tým spravuje vydané verze z hlediska správy verzí?

Váš tým by měl mít možnost vydat kód na konci jakéhokoli sprintu. Pomocí Team Foundation Serveru můžete označit větev a pořídit snímek kódu v určitém časovém okamžiku. Jak je znázorněno na následujícím obrázku, můžete pro vydání označit větev MAIN. To vám umožní vrátit větev do jejího stavu v tuto chvíli.

Vzhledem k tomu, že je nutné implementovat aktualizace pro vydané verze, vytvoření větve pro vydání pomáhá vašemu týmu pokračovat v práci na dalším sprintu bez nutnosti vytvářet konflikty s budoucími verzemi. Následující obrázek znázorňuje větev, která obsahuje kód aktualizace a která je po vydání na konci druhého sprintu integrovaná zpět do větve MAIN.

Když vytvoříte větev pro vydání verze, měli byste ji vytvořit z větve MAIN, což je nejstabilnější. Pokud větev vydáte z pracovní větve, může to způsobit problémy s integrací, protože stabilita pracovních větví není zaručená.

Související články

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