Udostępnij przez

Migrowanie do usługi Git z scentralizowanej kontroli wersji

Migrowanie zespołu do usługi Git ze scentralizowanej kontroli wersji wymaga więcej niż tylko uczenia się nowych poleceń. Aby obsługiwać programowanie rozproszone, usługa Git przechowuje informacje o historii plików i gałęziach inaczej niż scentralizowany system kontroli wersji. Planowanie i wdrażanie pomyślnej migracji do usługi Git ze scentralizowanego systemu kontroli wersji wymaga zrozumienia tych podstawowych różnic.

Firma Microsoft pomogła migrować wiele zespołów wewnętrznych i klientów z scentralizowanych systemów kontroli wersji do usługi Git. To środowisko opracowało następujące wskazówki oparte na praktykach, które konsekwentnie kończą się sukcesem.

Procedura pomyślnej migracji

W przypadku pomyślnej migracji zespoły powinny:

  • Ocenianie bieżących narzędzi i procesów.
  • Wybierz strategię rozgałęziania Git.
  • Zdecyduj, czy i jak przeprowadzić migrację historii.
  • Zachowaj poprzedni system kontroli wersji.
  • Usuń pliki binarne, pliki wykonywalne i narzędzia z kontroli źródła.
  • Trenowanie zespołów w zakresie pojęć i praktyk usługi Git.
  • Przetestuj migrację do usługi Git.

Ocena bieżących narzędzi i procesów

Zmiana systemów kontroli wersji naturalnie zakłóca przepływ pracy programowania przy użyciu nowych narzędzi i rozwiązań. Takie zakłócenia mogą być okazją do poprawy innych aspektów procesu DevOps.

Zespoły powinny rozważyć wdrożenie następujących rozwiązań podczas migracji do nowego systemu:

  • Ciągła integracja (CI), w której każde zatwierdzenie wyzwala kompilację i przejście testów. Ciągła integracja ułatwia wczesne identyfikowanie wad i zapewnia silną siatkę bezpieczeństwa dla projektów.

  • Wymagane przeglądy kodu przed zaewidencjonowaniem kodu. W modelu rozgałęziania Git przegląd kodu pull request jest częścią procesu rozwoju. Przeglądy kodu uzupełniają przepływ pracy ciągłej integracji.

  • Ciągłe dostarczanie (CD) w celu zautomatyzowania procesów wdrażania. Zmiana narzędzi kontroli wersji wymaga zmian w procesie wdrażania, dlatego migracja jest dobrym momentem na wdrożenie nowoczesnego kanału wydawniczego.

Wybieranie strategii rozgałęziania Git

Przed migracją kodu zespół powinien wybrać strategię rozgałęziania.

W systemie Git krótkotrwałe gałęzie tematyczne umożliwiają deweloperom pracę blisko głównej gałęzi i szybką integrację, unikając problemów z scalaniem. Dwie typowe strategie gałęzi roboczych to GitFlow i prostsza odmiana GitHub Flow.

Git zniechęca do długotrwałych, izolowanych gałęzi funkcjonalnych, które odkładają scalanie, aż integracja stanie się trudna. Wykorzystując nowoczesne techniki ciągłego wdrażania (CD), takie jak flagi funkcji, zespoły mogą szybko zintegrować kod z gałęzią główną, ukrywając je przed użytkownikami, aż do ich ukończenia.

Zespoły, które obecnie używają długotrwałej strategii gałęzi funkcji, mogą wdrażać flagi funkcji przed migracją do usługi Git. Używanie flag funkcjonalności upraszcza migrację, minimalizując liczbę gałęzi, które trzeba zmigrować. Niezależnie od tego, czy używają gałęzi funkcjonalności, czy przełączników funkcji, zespoły powinny udokumentować mapowanie między starszymi gałęziami Git i nowymi gałęziami Git, aby wszyscy zrozumieli, gdzie dokonywać nowych zatwierdzeń.

Zdecyduj, czy chcesz przeprowadzić migrację historii

Zespoły mogą być skłonne do migracji istniejącej historii kodu źródłowego do usługi Git. Kilka narzędzi twierdzi, że przeprowadzi migrację pełnej historii wszystkich gałęzi ze scentralizowanego narzędzia do usługi Git. Zatwierdzenie Git wydaje się dość dobrze odpowiadać zestawowi zmian lub modelowi określeń używanemu przez poprzednie narzędzie kontroli wersji.

Jednak to mapowanie ma pewne poważne ograniczenia.

  • W większości scentralizowanych systemów kontroli wersji gałęzie istnieją jako foldery w repozytorium. Na przykład gałąź główna może być folderem o nazwie /trunk, a inne gałęzie są folderami takimi jak /branch/one i /branch/two. W repozytorium Git gałęzie zawierają całe repozytorium, więc tłumaczenie 1:1 jest trudne.

  • W niektórych systemach kontroli wersji tag lub etykieta to kolekcja, która może zawierać różne pliki w drzewie, nawet pliki w różnych wersjach. W usłudze Git tag jest migawką całego repozytorium w określonym punkcie w czasie. Tag nie może reprezentować podzbioru repozytorium ani łączyć plików w różnych wersjach.

  • Większość systemów kontroli wersji przechowuje szczegółowe informacje o sposobie zmiany plików między wersjami, w tym szczegółowe typy zmian, takie jak zmiana nazwy, cofanie i wycofywanie. Usługa Git przechowuje wersje jako migawki całego repozytorium, a metadane dotyczące sposobu zmiany plików nie są dostępne.

Te różnice oznaczają, że pełna migracja historii będzie w najlepszym razie obarczona stratami i może prowadzić do błędnych interpretacji. Biorąc pod uwagę straty, nakład pracy i względną rzadkość korzystania z historii, zaleca się, aby większość zespołów unikała importowania historii. Zamiast tego zespoły powinny przeprowadzić migrację najnowszej wersji, przenosząc tylko migawkę najnowszej wersji gałęzi do repozytorium Git. W przypadku większości zespołów najlepiej poświęcać czas na obszary migracji, które mają wyższy zwrot z inwestycji, takich jak ulepszanie procesów.

Obsługa starego systemu kontroli wersji

Podczas migracji i po migracji deweloperzy mogą nadal potrzebować dostępu do poprzedniej historii kontroli wersji. Mimo że poprzednia historia kontroli wersji staje się mniej istotna w miarę upływu czasu, nadal ważne jest, aby móc się do niej odwołać. Wysoce regulowane środowiska mogą mieć określone wymagania prawne i inspekcji dotyczące historii kontroli wersji.

Szczególnie w przypadku zespołów, które wykonują tylko migrację tipów, jest wysoce zalecane utrzymanie poprzedniego systemu na czas nieokreślony. Ustaw stary system kontroli wersji na tylko do odczytu po migracji.

Duże zespoły programistyczne i regulowane środowiska mogą umieszczać ślady w Git, które wskazują na stary system kontroli wersji. Prostym przykładem jest plik tekstowy dodany jako pierwszy commit w katalogu głównym repozytorium Git, przed migracją końcówki, który wskazuje na URL starego serwera kontroli wersji. Jeśli wiele gałęzi migruje, plik tekstowy w każdej gałęzi powinien wyjaśnić, jak gałęzie migrowały ze starego systemu. Ścieżki nawigacyjne są również przydatne dla deweloperów, którzy zaczynają pracę nad projektem po migracji, gdy nie są zaznajomieni ze starym systemem kontroli wersji.

Usuwanie plików binarnych i narzędzi

Model magazynu usługi Git jest zoptymalizowany pod kątem przechowywania wersji plików tekstowych i kodu źródłowego, które są kompaktowe i wysoce kompresowalne. Pliki binarne są zwykle duże i po dodaniu ich do repozytorium pozostają w historii repozytorium i w każdym przyszłym klonie. Ze względu na sposób przechowywania historii usługi Git deweloperzy powinni unikać dodawania plików binarnych do repozytoriów, zwłaszcza plików binarnych, które są bardzo duże lub często się zmieniają. Migracja do usługi Git jest okazją do usunięcia tych plików binarnych z bazy kodu.

Zaleca się również wykluczanie bibliotek, narzędzi i kompilowania danych wyjściowych z repozytoriów. Zamiast tego użyj systemów zarządzania pakietami, takich jak NuGet, aby zarządzać zależnościami.

Zasoby, takie jak ikony i grafika, mogą wymagać dostosowania do określonej wersji kodu źródłowego. Małe, rzadko zmieniane elementy, takie jak ikony, nie będą zapychać historii i można je uwzględnić bezpośrednio w repozytorium. Aby przechowywać duże lub często zmieniające się zasoby, użyj rozszerzenia Git Large File Storage (LFS). Aby uzyskać więcej informacji na temat zarządzania dużymi plikami w usłudze GitHub, zobacz Zarządzanie dużymi plikami. W przypadku usługi Azure Repos zobacz Zarządzanie dużymi plikami i przechowywanie ich w usłudze Git.

Zapewnianie szkolenia

Jednym z największych wyzwań związanych z migracją do Git jest pomoc programistom w zrozumieniu, w jaki sposób Git przechowuje zmiany oraz jak commit-y kształtują historię rozwoju. Nie wystarczy przygotować pomocniczej instrukcji, która odnosi stare polecenia na polecenia Git. Deweloperzy muszą przestać myśleć o historii kontroli wersji pod względem scentralizowanego, liniowego modelu i zrozumienia modelu historii usługi Git i grafu zatwierdzeń.

Ludzie uczą się na różne sposoby, więc należy udostępnić kilka rodzajów materiałów szkoleniowych. Szkolenie na żywo w laboratorium z instruktorem ekspertem działa dobrze dla niektórych osób. Książka Pro Git jest doskonałym punktem wyjścia, który jest dostępny bezpłatnie online.

Dostępne bezpłatne kursy szkoleniowe obejmują:

Organizacje powinny pracować nad zidentyfikowaniem ekspertów usługi Git w zespołach, umożliwienie im pomocy innym osobom i zachęcanie innych członków zespołu do zadawania pytań.

Testowanie migracji

Gdy zespoły aktualizują swoje procesy, analizują kod i trenują członków, nadszedł czas na migrację kodu źródłowego. Niezależnie od tego, czy przeprowadzasz migrację końcówek, czy migrację historii, ważne jest, aby wykonać jedną lub więcej migracji testowych do repozytorium testowego. Przed zakończeniem migracji upewnij się, że:

  • Wszystkie pliki kodu są migrowane.
  • Wszystkie gałęzie są dostępne.
  • W repozytorium nie ma bezpańskich plików binarnych.
  • Użytkownicy mają odpowiednie uprawnienia do pobierania i wypychania.
  • Kompilacje zakończyły się pomyślnie, a wszystkie testy zakończyły się powodzeniem.

Migrowanie kodu

Wykonaj ostateczną migrację poza godzinami pracy, najlepiej między etapami, gdy wystąpi naturalny przestój. Migracja na koniec sprintu może powodować problemy, gdy deweloperzy próbują zakończyć swoje zadania. Spróbuj przeprowadzić migrację w weekend, kiedy nikt nie musi się zaewidencjonować.

Zaplanuj zdecydowane przejście ze starego systemu kontroli wersji na system Git. Próba obsługi wielu systemów równolegle oznacza, że deweloperzy mogą nie wiedzieć, gdzie lub jak się zaewidencjonować. Ustaw stary system kontroli wersji na tylko do odczytu, aby uniknąć nieporozumień. Bez tego zabezpieczenia może być konieczna druga migracja obejmująca zmiany tymczasowe.

Rzeczywisty proces migracji różni się w zależności od systemu, z którego przeprowadzasz migrację. Aby uzyskać informacje na temat migracji z kontroli wersji programu Team Foundation, zobacz Migrowanie z serwera TFVC do usługi Git.

Lista kontrolna migracji

Przepływy pracy zespołu:

  • Określ sposób przebiegu kompilacji.
  • Zdecyduj, kiedy zostaną uruchomione testy.
  • Opracowywanie procesu zarządzania wydaniami.
  • Przenieś przeglądy kodu do pull requestów.

Strategia rozgałęziania:

  • Wybierz strategię gałęzi w Git.
  • Udokumentowanie strategii rozgałęziania, przyczyn jej wybrania oraz sposobu mapowania starszych gałęzi.

History:

  • Zdecyduj, jak długo ma być uruchomiony stary system kontroli wersji.
  • Zidentyfikuj gałęzie, które muszą zostać zmigrowane.
  • W razie potrzeby utwórz nawigację ścieżkową, aby ułatwić inżynierom powrót do starszego systemu.

Pliki binarne i narzędzia:

  • Zidentyfikuj pliki binarne i nieuszyfnione do usunięcia z repozytorium.
  • Zdecyduj się na podejście do dużych plików, takich jak Git-LFS.
  • Zdecyduj się na podejście do dostarczania narzędzi i bibliotek, takich jak NuGet.

Szkolenie:

  • Identyfikowanie materiałów szkoleniowych.
  • Planowanie wydarzeń szkoleniowych, materiałów napisanych i filmów wideo.
  • Zidentyfikuj członków zespołu, którzy będą służyć jako lokalni eksperci git.

Migracja kodu:

  • Wykonaj wiele przebiegów testów, aby upewnić się, że migracja przebiegnie bezproblemowo.
  • Określenie i komunikowanie czasu zmiany.
  • Utwórz nowe repozytorium Git.
  • Ustaw stary system w tryb tylko do odczytu.
  • Najpierw przeprowadź migrację gałęzi głównej, a następnie wszelkie inne potrzebne gałęzie.

Dalsze kroki

  • Last updated on