Sdílet prostřednictvím

Migrace na Git z centralizované správy verzí

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:

  • Kontinuální integrace (CI), kde každé vytvoření změn spouští sestavení a testování. CI pomáhá včas identifikovat vady a poskytuje silnou bezpečnostní síť pro projekty.

  • Požadované kontroly kódu před odevzdáním kódu. V modelu větvení Gitu je kontrola kódu pull requestu součástí procesu vývoje. Revize kódu doplňují pracovní postup CI.

  • Průběžné doručování (CD) pro automatizaci procesů nasazení Změna nástrojů pro správu verzí vyžaduje změny v procesu nasazení, takže migrace je vhodný čas na zavedení moderního vydávacího systému.

Vyberte strategii větvení Git

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 dlouho trvající oddělené funkční větve, které mají tendenci zpožďovat sloučení, což ztěžuje následnou integraci. 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 by mohly být zlákat k migraci stávající historie zdrojového kódu do Git. Několik nástrojů deklaruje migraci úplné historie všech větví z centralizovaného nástroje do Gitu. Zdá se, že Git commit je poměrně dobře mapován na changeset nebo check-in model, 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ě detailních typů změn, jako je přejmenování, obnovení smazání 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átová a navíc 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 migraci a zahrnout do Gitu pouze 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í.

Zejména pro týmy, které provádějí pouze migraci tipového typu, se důrazně doporučuje udržovat předchozí systém na neurčito. 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 stopy, 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é soubory, které se zřídka mění, jako jsou ikony, nenafouknou 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.

Poskytování š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 commity tvoří historii vývoje. Nestačí připravit tahák, který mapuje staré příkazy na příkazy Git. 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čí různými způsoby, takže byste měli poskytnout několik typů školicích materiálů. Živé školení v laboratoři se zkušeným instruktorem dobře funguje pro některé lidi. 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. Ať už provádíte migraci tipu nebo migraci historie, 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 odeslání 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. Provoz více systémů současně znamená, že vývojáři nemusí vědět, kde nebo jak provést kontrolu. 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 ze správy 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 buildy spouštět.
  • Rozhodněte se, kdy se testy spustí.
  • Vývoj procesu správy verzí
  • Přesuňte kontroly kódu do pull requestů.

Strategie větvení:

  • Vyberte strategii větvení pro Git.
  • Zdokumentujte strategii větvení, důvody jejího výběru, a jak se mapují historické větve.

History:

  • 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 čas přechodu.
  • 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

  • Last updated on