Udostępnij za pośrednictwem

Migrowanie do usługi Git z scentralizowanej kontroli wersji

  • Artykuł

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, w której każde zaewidencjonowanie wyzwala kompilację i test. Ciągła integracja ułatwia wczesne identyfikowanie wad i zapewnia silną siatkę bezpieczeństwa dla projektów.

  • Wymagane przeglądy kodu przed zaewidencjonowanie kodu. W modelu rozgałęziania git przegląd kodu żądania ściągnięcia jest częścią procesu programowania. 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 procesu wdrażania, dlatego migracja jest dobrym momentem na wdrożenie nowoczesnego potoku wydania.

Wybieranie strategii rozgałęziania git

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

W usłudze Git krótkotrwałe gałęzie tematów umożliwiają deweloperom pracę w pobliżu głównej gałęzi i szybką integrację, unikając problemów ze scalaniami. Dwie typowe strategie gałęzi tematów to GitFlow i prostsza odmiana usługi GitHub Flow.

Usługa Git zniechęca do długotrwałych, izolowanych gałęzi funkcji, które zwykle opóźniają scalanie, dopóki integracja nie stanie się trudna. Dzięki użyciu nowoczesnych technik ciągłego wdrażania, takich jak flagi funkcji, zespoły mogą szybko zintegrować kod z gałęzią główną, ale nadal zachować funkcje w toku ukryte przed użytkownikami, dopóki nie zostaną ukończone.

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 funkcji upraszcza migrację, minimalizując liczbę gałęzi do migracji. Niezależnie od tego, czy używają gałęzi funkcji, czy flag funkcji, zespoły powinny udokumentować mapowanie między starszymi gałęziami i nowymi gałęziami Git, aby wszyscy zrozumieli, gdzie zatwierdzić nową pracę.

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ę mapować stosunkowo dobrze na zestaw zmian lub zaewidencjonować model używany 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 etykietato 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 stratą i prawdopodobnie myląca. 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ę porad, przenosząc tylko migawkę najnowszej wersji gałęzi do usługi 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 odpowiednia w miarę upływu czasu, nadal ważne jest, aby móc się z nią odwoływać. 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ę porad, zdecydowanie zaleca się 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ć linki do stron nadrzędnych w usłudze Git, które wskazują stary system kontroli wersji. Prostym przykładem jest plik tekstowy dodany jako pierwsze zatwierdzenie w katalogu głównym repozytorium Git przed migracją porad, który wskazuje adres URL starego serwera kontroli wersji. W przypadku migracji wielu gałęzi plik tekstowy w każdej gałęzi powinien wyjaśnić, w jaki sposób gałęzie migrowane ze starego systemu. Linki do stron nadrzędnych są również przydatne dla deweloperów, którzy zaczynają pracę nad projektem po migracji i nie znają starego systemu 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 zasoby, takie jak ikony, nie będą wdęć 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 usługi Git jest pomoc deweloperom w zrozumieniu, w jaki sposób usługa Git przechowuje zmiany i jak zatwierdza historię programowania formularzy. Nie wystarczy przygotować ściągawkę, która mapuje 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ń.

Osoby nauczyć się na różne sposoby, dlatego należy udostępnić kilka rodzajów materiałów szkoleniowych. Na żywo, oparte na laboratorium szkolenia z instruktorem ekspertów 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ę porad, czy historię migracji, ważne jest, aby wykonać co najmniej jedną migrację testową 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ę w godzinach pracy, najlepiej między kamieniami milowymi, gdy wystąpi naturalny przestój. Migracja na koniec przebiegu może powodować problemy, gdy deweloperzy próbują zakończyć pracę. Spróbuj przeprowadzić migrację w weekend, kiedy nikt nie musi się zaewidencjonować.

Zaplanuj odcięcie od starego systemu kontroli wersji do usługi 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 migrowania z Kontrola wersji serwera Team Foundation, zobacz Migrowanie z serwera TFVC do usługi Git.

Lista kontrolna migracji

Przepływy pracy zespołu:

  • Określ sposób uruchamiania kompilacji.
  • Zdecyduj, kiedy zostaną uruchomione testy.
  • Opracowywanie procesu zarządzania wydaniami.
  • Przenoszenie przeglądów kodu do żądań ściągnięcia.

Strategia rozgałęziania:

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

Historia:

  • Zdecyduj, jak długo ma być uruchomiona starsza kontrola wersji.
  • Identyfikowanie gałęzi, które muszą być migrowane.
  • W razie potrzeby utwórz linki do stron nadrzędnych, 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.
  • Identyfikowanie i komunikowanie czasu jednorazowego.
  • Utwórz nowe repozytorium Git.
  • Ustaw stary system na tylko do odczytu.
  • Najpierw przeprowadź migrację gałęzi głównej, a następnie wszelkie inne potrzebne gałęzie.

Następne kroki