Sdílet prostřednictvím

Migrace na Git z centralizované správy verzí

  • Článek

Migrace týmu do Gitu z centralizované správy verzí vyžaduje víc než jen učení nových příkazů. Pro podporu distribuovaného vývoje ukládá Git informace o historii souborů a větvích jinak než centralizovaný systém správy verzí. Plánování a implementace úspěšné migrace do Gitu z centralizovaného systému správy verzí vyžaduje pochopení těchto základních rozdílů.

Microsoft pomohl migrovat mnoho interních týmů a zákazníků z centralizovaných systémů správy verzí do Gitu. Tato zkušenost vytvořila následující doprovodné materiály založené na postupech, které konzistentně uspěly.

Kroky pro úspěšnou migraci

Pro úspěšnou migraci by týmy měly:

  • Vyhodnocení aktuálních nástrojů a procesů
  • Vyberte strategii větvení Gitu.
  • Rozhodněte se, jestli a jak migrovat historii.
  • Udržujte předchozí systém správy verzí.
  • Odeberte binární soubory, spustitelné soubory a nástroje ze správy zdrojového kódu.
  • Trénujte týmy v konceptech a postupech Gitu.
  • Otestujte migraci na Git.

Vyhodnocení aktuálních nástrojů a procesů

Změna systémů správy verzí přirozeně naruší pracovní postup vývoje novými nástroji a postupy. Toto přerušení může být příležitostí ke zlepšení dalších aspektů procesu DevOps.

Týmy by měly zvážit přijetí následujících postupů při migraci do nového systému:

Výběr strategie větvení Gitu

Před migrací kódu by tým měl vybrat strategii větvení.

Krátkodobé větve témat v Gitu umožňují vývojářům pracovat blízko hlavní větve a rychle se integrovat a vyhnout se problémům se sloučením. Dvě běžné strategie větve tématu jsou GitFlow a jednodušší varianta, GitHub Flow.

Git nedoporučuje dlouhotrvající izolované větve funkcí, které mají tendenci zpožďovat sloučení, dokud nebude integrace obtížná. Díky moderním technikám CD, jako jsou příznaky funkcí, můžou týmy rychle integrovat kód do hlavní větve, ale stále udržovat probíhající funkce skryté uživatelům, dokud nebudou dokončené.

Týmy, které aktuálně používají dlouhodobou strategii větvení funkcí, můžou před migrací na Git přijmout příznaky funkcí. Použití příznaků funkcí zjednodušuje migraci minimalizací počtu větví, které se mají migrovat. Ať už používají větve funkcí nebo příznaky funkcí, týmy by měly dokumentovat mapování mezi staršími větvemi a novými větvemi Gitu, takže všichni vědí, kde se má nová práce potvrdit.

Rozhodnutí o tom, jestli se má migrovat historie

Týmy můžou být lákavé k migraci stávající historie zdrojového kódu do Gitu. Několik nástrojů deklaruje migraci úplné historie všech větví z centralizovaného nástroje do Gitu. Zdá se, že potvrzení Gitu je poměrně dobře namapované na sadu změn nebo na model vrácení se změnami, který použil předchozí nástroj pro správu verzí.

Toto mapování má ale určitá závažná omezení.

  • Ve většině centralizovaných systémů správy verzí existují větve jako složky v úložišti. Například hlavní větev může být složka s názvem /trunk a další větve jsou složky jako /branch/one a /branch/two. Větve v úložišti Git zahrnují celé úložiště, takže překlad 1:1 je složitý.

  • V některých systémech správy verzí je značka nebo popisek kolekce, která může obsahovat různé soubory ve stromu, a to i soubory v různých verzích. V Gitu je značka snímkem celého úložiště v určitém časovém okamžiku. Značka nemůže reprezentovat podmnožinu úložiště ani kombinovat soubory v různých verzích.

  • Většina systémů správy verzí ukládá podrobnosti o způsobu, jakým se soubory mezi verzemi mění, včetně jemně odstupňovaných typů změn, jako je přejmenování, zrušení zrušení a vrácení zpět. Git ukládá verze jako snímky celého úložiště a metadata o způsobu, jakým se změnily soubory, nejsou k dispozici.

Tyto rozdíly znamenají, že úplná migrace historie bude v nejlepším případě ztráta a pravděpodobně zavádějící. Vzhledem ke ztrátě, úsilí a relativní raritě používání historie se doporučuje, aby se většina týmů vyhnula importu historie. Místo toho by týmy měly provést tip k migraci a přinést do Gitu jenom snímek nejnovější verze větve. Pro většinu týmů je čas nejvhodnější pro oblasti migrace, které mají vyšší návratnost investic, jako je zlepšení procesů.

Údržba starého systému správy verzí

Během migrace a po migraci můžou vývojáři stále potřebovat přístup k předchozí historii správy verzí. I když předchozí historie správy verzí je v průběhu času méně relevantní, je stále důležité, abyste na ni mohli odkazovat. Vysoce regulovaná prostředí můžou mít specifické právní a auditní požadavky pro historii správy verzí.

Zvláště pro týmy, které dělají pouze tip migrace, se důrazně doporučuje udržovat předchozí systém neomezeně dlouho. Po migraci nastavte starý systém správy verzí na jen pro čtení.

Velké vývojové týmy a regulovaná prostředí můžou v Gitu umístit popis cesty , které odkazují zpět na starý systém správy verzí. Jednoduchým příkladem je textový soubor přidaný jako první potvrzení v kořenovém adresáři úložiště Git před migrací tipu, který odkazuje na adresu URL starého serveru správy verzí. Pokud migruje mnoho větví, měl by textový soubor v každé větvi vysvětlit, jak se větve migrovaly ze starého systému. Popis cesty je také užitečný pro vývojáře, kteří začnou pracovat na projektu po migraci a nejsou obeznámeni se starým systémem správy verzí.

Odebrání binárních souborů a nástrojů

Model úložiště Gitu je optimalizovaný pro správu verzí textových souborů a zdrojového kódu, které jsou kompaktní a vysoce komprimovatelné. Binární soubory jsou obvykle velké a jakmile se přidají do úložiště, zůstanou v historii úložiště a v každém budoucím klonování. Vzhledem ke způsobu, jakým Git ukládá historii, by se vývojáři měli vyhnout přidávání binárních souborů do úložišť, zejména binárních souborů, které jsou velmi velké nebo se často mění. Migrace na Git je příležitost odebrat tyto binární soubory ze základu kódu.

Doporučuje se také vyloučit knihovny, nástroje a výstup sestavení z úložišť. Místo toho ke správě závislostí používejte systémy pro správu balíčků, jako je NuGet.

Prostředky, jako jsou ikony a kresby, můžou být potřeba sladit s konkrétní verzí zdrojového kódu. Malé, zřídka změněné prostředky, jako jsou ikony, nebudou bloudit historii a můžete je zahrnout přímo do úložiště. Pokud chcete ukládat velké nebo často se měnící prostředky, použijte rozšíření Git Large File Storage (LFS). Další informace o správě velkých souborů na GitHubu najdete v tématu Správa velkých souborů. Informace o Azure Repos najdete v tématu Správa a ukládání velkých souborů v Gitu.

Proškolení

Jedním z největších problémů při migraci na Git je pomoct vývojářům pochopit, jak Git ukládá změny a jak potvrzení historie vývoje formulářů. Nestačí připravit tahák, který mapuje staré příkazy na příkazy Gitu. Vývojáři musí přestat přemýšlet o historii správy verzí z hlediska centralizovaného, lineárního modelu a pochopení modelu historie Gitu a grafu potvrzení.

Lidé se učit různými způsoby, takže byste měli poskytnout několik typů školicích materiálů. Live, lab-based training with an expert instructor works well for some people. Kniha Pro Git je skvělým výchozím bodem, který je k dispozici zdarma online.

Mezi dostupné bezplatné praktické školicí kurzy patří:

Organizace by měly spolupracovat na identifikaci odborníků na Git v týmech, umožnit jim pomoct ostatním a podpořit ostatní členy týmu, aby se na ně ptali.

Otestování migrace

Jakmile týmy aktualizují své procesy, analyzují kód a trénují členy, je čas migrovat zdrojový kód. Bez ohledu na to, jestli provedete migraci tipu nebo historii migrace, je důležité provést jednu nebo více testovacích migrací do testovacího úložiště. Před dokončením migrace se ujistěte, že:

  • Migrují se všechny soubory kódu.
  • Všechny větve jsou k dispozici.
  • V úložišti nejsou žádné strašidné binární soubory.
  • Uživatelé mají příslušná oprávnění k načtení a nasdílení změn.
  • Sestavení jsou úspěšná a všechny testy jsou úspěšné.

Migrace kódu

Proveďte konečnou migraci během mimopracovní doby, ideálně mezi milníky, když dojde k přirozenému výpadku. Migrace na konci sprintu může způsobit problémy, když se vývojáři snaží dokončit práci. Zkuste migrovat o víkendu, když se nikdo nemusí přihlásit.

Naplánujte si přímou migraci ze starého systému správy verzí do Gitu. Pokus o paralelní provoz více systémů znamená, že vývojáři nemusí vědět, kde nebo jak se vrátit se změnami. Nastavte starý systém správy verzí na jen pro čtení, abyste se vyhnuli nejasnostem. Bez tohoto zabezpečení může být nutná druhá migrace, která zahrnuje dočasné změny.

Skutečný proces migrace se liší v závislosti na systému, ze kterém migrujete. Informace o migraci z Správa verzí Team Foundation najdete v tématu Migrace z TFVC na Git.

Kontrolní seznam pro migraci

Týmové pracovní postupy:

  • Určete, jak se budou sestavení spouštět.
  • Rozhodněte se, kdy se testy spustí.
  • Vývoj procesu správy verzí
  • Přesuňte kontroly kódu do žádostí o přijetí změn.

Strategie větvení:

  • Vyberte strategii větvení Gitu.
  • Zdokumentujte strategii větvení, proč byla vybrána a jak se mapují starší větve.

Historie:

  • Rozhodněte se, jak dlouho má starší verze správy verzí běžet.
  • Identifikujte větve, které je potřeba migrovat.
  • V případě potřeby vytvořte popis cesty, který technikům pomůže přejít zpět do starší verze systému.

Binární soubory a nástroje:

  • Určete, které binární soubory a nepovolitelné soubory se mají z úložiště odebrat.
  • Rozhodněte se o přístupu pro velké soubory, jako je Git-LFS.
  • Rozhodněte se o přístupu pro doručování nástrojů a knihoven, jako je NuGet.

Trénování:

  • Identifikujte školicí materiály.
  • Naplánujte školicí akce, písemné materiály a videa.
  • Identifikujte členy týmu, kteří budou sloužit jako místní odborníci na Git.

Migrace kódu:

  • Proveďte několik testovacích spuštění, abyste zajistili, že migrace proběhne hladce.
  • Identifikujte a komunikujte přímou dobu.
  • Vytvořte nové úložiště Git.
  • Nastavte starý systém na jen pro čtení.
  • Nejprve migrujte hlavní větev a pak všechny ostatní potřebné větve.

Další kroky