Przewodnik krok po kroku dotyczący migracji z Perforce do Git

Jak omówiliśmy w poprzednim artykule, Git jest teraz domyślnym wyborem w ramach procesu zarządzania łańcuchem dostaw do tworzenia niemal każdego rodzaju produktów cyfrowych. Jeśli jednak przechowujesz w Perforce cenną historię z wielu lat, prawdopodobnie analizujesz koszt zmiany rozwiązania. W tym artykule zajmiemy się tymi kwestiami i powiemy, jak przeprowadzić migrację danych do Git. Podzieliliśmy proces migracji z Perforce do Git na 8 kroków:

Przenoszenie danych Perforce
Mapowanie użytkowników i uprawnień do nowego repozytorium Git
Duże pliki binarne
Złożone zależności
Organizacja zespołu podczas migracji
Tworzenie kopii lustrzanych danych
Narzędzia ALM
Jak zdefiniować pomyślną migrację Perforce do Git

Krok 1. Przenoszenie danych Perforce

Istnieją dwa ogólne podejścia do przenoszenia danych z Perforce do Git. Zanim przejdziemy do szczegółów, musimy rozważyć zasadniczą różnicę między sposobem obsługi projektów oprogramowania w narzędziach Perforce i Git.

Serwer Perforce może pomieścić dziesiątki lub setki różnych projektów oprogramowania, każdy z własnym modelem tworzenia gałęzi. Programista definiuje widok informujący serwer Perforce, które pliki umieścić w kopii roboczej. Natomiast repozytorium Git zwykle zawiera pojedynczy projekt oprogramowania oraz jego gałęzie i tagi (chociaż istnieją duże monolityczne repozytoria Git). Zazwyczaj klonujesz repozytorium i być może wyewidencjonowujesz podmoduły lub poddrzewa.

Kwestia przenoszenia danych obejmuje zatem dwa elementy: jak wyodrębnić dane z Perforce i jak zamienić je na równoważny zestaw repozytoriów Git.

Przenoszenie danych Perforce — opcja 1: użycie Git Fusion

Jeśli chcesz zachować całą historię swoich danych w Perforce, możesz użyć własnego narzędzia Perforce o nazwie Git Fusion, aby wyodrębnić sekcję serwera Perforce (pojedynczego projektu) do repozytorium Git. Wykonaj te kroki:

Zainstaluj Git Fusion.
Skonfiguruj poprawne widoki danych, w tym struktury gałęzi.
Użyj dowolnego klienta Git do klonowania z Git Fusion.
Wypchnij swoje repozytorium do Bitbucket.

 Przykład praktyczny *Aby wykonać czynności przedstawione w tym przykładzie, musisz mieć działający serwer Perforce z Git Fusion.* Powiedzmy, że masz projekt Perforce znajdujący się w ścieżce repozytorium //depot/acme/... (w składni widoku magazynu Perforce). Ma on trzy gałęzie: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Pamiętaj, że w Perforce widzisz gałęzie jako dodatkowe katalogi w drzewie. Pierwszym krokiem jest takie skonfigurowanie narzędzia Git Fusion, aby rozumiało ono relacje gałęzi w Perforce. W tym celu należy utworzyć plik konfiguracyjny repozytorium: [@repo] description = Projekt Acme charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Prześlij ten plik do katalogu Perforce: //.git-fusion/repos/acme/p4gf_config Teraz utwórz pusty projekt o nazwie acme w Bitbucket, używając zwykłych narzędzi administracyjnych Bitbucket. Możesz skonfigurować kontrolę dostępu i członków zespołu w zwykły sposób. Następnie wykonaj klonowanie z Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket Gotowe! Zaimportowana historia powinna być teraz widoczna w Bitbucket.

Nie zawsze pozwala to uzyskać w pełni wierną kopię danych Perforce. Istnieją pewne operacje Perforce, takie jak częściowe scalenia, które po prostu nie mają odpowiednika w Git. Ogólnie ta metoda pozwoli jednak uzyskać większość historii bez zbytniego wysiłku.

Pamiętaj, że potrzeba zachowania ostatnich 10 lat historii tworzenia gałęzi ze starszego systemu zarządzania łańcuchem dostaw nie oznacza, że musisz nadal korzystać z tego samego przepływu pracy. Szczególnie należy rozważyć przyjęcie przepływów pracy gałęzi funkcji, takich jak Git Flow, jako praktycznego pierwszego kroku.

Plusy i minusy

Wymaga najwięcej prac konfiguracyjnych i środowiska wykonawczego.
Zachowuje najwięcej historii (umożliwiając wyłączenie starszego serwera Perforce).
Zachowuje starszy model tworzenia gałęzi w historii.

Przenoszenie danych perforce — opcja 2: rozpoczęcie od nowa

Inną opcją jest rozpoczęcie od nowa. Zapomnij o całej tej zbędnej historii — po prostu wyodrębnij końcową część każdej gałęzi w Perforce, która odpowiada Twojemu projektowi, i zaewidencjonuj ją w nowym, pustym repozytorium Git. (Oznacza to, że masz przestrzenie robocze Perforce zdefiniowane z poprawnym „widokiem” danych, których potrzebujesz).

Jest to najprostszy i najszybszy sposób. Bez względu na to, jak skomplikowana była Twoja historia Perforce, nowe repozytorium Git jest gotowe do efektywnej pracy. Masz szansę na rozpoczęcie nowego przepływu opartego na Git bez nagromadzonych elementów.

Główną wadą tej opcji jest to, że prawdopodobnie warto zachować stary serwer Perforce w trybie tylko do odczytu na wypadek, gdyby z jakiegoś powodu ktoś musiał zajrzeć do starego kodu. Nie poniesiesz kosztów opłat licencyjnych, ale przez jakiś czas trzeba będzie utrzymywać stary serwer.

 **Przykład praktyczny** Przejdź do obszaru roboczego Perforce (czyli katalogu, w którym jest wyewidencjonowana gałąź main danych projektu) i uruchom polecenie: p4 sync Spowoduje to pobranie najnowszej wersji plików. Teraz utwórz pusty projekt o nazwie acme w Bitbucket, używając zwykłych narzędzi administracyjnych Bitbucket. Możesz skonfigurować kontrolę dostępu i członków zespołu w zwykły sposób. Następnie utwórz nowe repozytorium Git w obszarze roboczym i przejdź do Bitbucket: git init . git remote add origin  git push –u --all origin git push --tags origin Teraz najnowsza migawka kodu powinna być widoczna jako pierwszy commit w nowym projekcie Bitbucket.

Plusy i minusy

Szybkie i proste rozwiązanie
Przeprojektowanie modelu tworzenia gałęzi i przepływu pracy
Starszy serwer Perforce w trybie tylko do odczytu

Krok 2. Użytkownicy i uprawnienia

Po przeniesieniu danych następnym zadaniem jest zazwyczaj rozpoczęcie mapowania użytkowników i uprawnień do nowych projektów Bitbucket. Jeśli używasz LDAP w przypadku katalogu użytkownika, zaoszczędzisz tutaj trochę czasu. W przeciwnym razie możesz łatwo wyodrębnić zestaw kont użytkowników z Perforce za pomocą polecenia p4 users –o, a następnie wprowadzić je do Bitbucket po jednym projekcie.

Mapowanie uprawnień Perforce na równoważne uprawnienia Bitbucket może być trudne, ponieważ uprawnienia Perforce są szczegółowe i złożone, z możliwością wykluczenia dostępu do poszczególnych plików. Ten skomplikowany schemat uprawnień jest jednym z powodów, dla których serwer Perforce może działać wolniej — każda próba dostępu może spowodować, że serwer wykona wymagające obliczenia na skomplikowanej strukturze danych.

W większości przypadków szybciej jest po prostu poprosić liderów projektu o zdefiniowanie prostszego zestawu uprawnień w Bitbucket przy użyciu normalnych uprawnień do projektu, repozytorium i poziomu gałęzi. W rzeczywistości i tak trzeba będzie ponownie zapoznać się z konfiguracją uprawnień, ponieważ Git oferuje wiele nowych opcji przepływu pracy. Na przykład w Perforce możesz mieć ograniczenia tworzenia gałęzi, a w Bitbucket może być konieczne tylko ograniczenie dostępu do wypychania do głównej gałęzi.

Krok 3. Pliki binarne

Jeśli w Perforce przechowywano duże obiekty blob, zastanów się dobrze, jak chcesz nimi zarządzać w Git. Możesz wypróbować Git LFS lub po prostu użyć zwykłego systemu zarządzania artefaktami. W każdym razie nie warto bez zastanowienia wypychać dużych obiektów blob do repozytorium Git.

Krok 4. Złożone zależności

Kopia robocza Perforce może faktycznie mapować kopie danych tylko do odczytu z kilku modułów. W Git odbywa się to za pomocą podmodułów, poddrzew lub poprzez wykorzystanie systemów zarządzania CI/CD lub artefaktami. Nie ma tu łatwej odpowiedzi, ale niektóre narzędzia do importu danych mogą modelować relację podmodułu między repozytoriami Git. Aby uzyskać bardziej szczegółowe spojrzenie na korzystanie z podmodułów lub poddrzew, możesz przeczytać o poszczególnych rozwiązaniach tutaj: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/.

Krok 5. Jak zorganizować swój zespół podczas migracji

Twój serwer Perforce zawiera 100 projektów tworzonych przez 10 zespołów. Masz opracowaną strategię migracji i zestaw narzędzi. Zaplanuj okno przerwy technicznej i działaj!

To nie takie proste.

Pamiętaj, że zmiana narzędzi procesu zarządzania łańcuchem dostaw dotyczy zarówno programistów, jak i danych. Masz do rozważenia ludzi, proces i harmonogram — nie rób wszystkiego naraz. To zbyt ryzykowne.

Weź pod uwagę plan projektu podczas faktycznej fazy migracji. (To może być dobry moment, aby wypróbować nowy przepływ pracy Jira). Oto kilka opcji, którym możesz się przyjrzeć.

Przeprowadzaj kolejno migrację poszczególnych zespołów i projektów. Postaraj się rozpocząć projekt i ustanowić zespół na początku sprintu lub przyrostu programu, kiedy masz trochę czasu na adaptację.
Wykonuj migrację stopniowo. Zaimportuj wszystkie swoje dane w weekend, ale z czasem pozwól zespołom powoli przełączyć się na Git. Okresowo pobieraj różnice, ponownie uruchamiając narzędzia importu. Chociaż ta strategia jest bardziej złożona, nie jest zła, jeśli masz zależności między zespołami, a pierwsi użytkownicy potrzebują przynajmniej ostatniej migawki w Git, aby wprowadzić ją do swojego pipeline'u CI/CD.
Używaj obu systemów jednocześnie przez pewien czas. Chociaż jest to rozwiązanie dla osób o mocnych nerwach, technicznie możliwe jest użycie Git Fusion do dwukierunkowej wymiany danych, o ile nie wykonujesz skomplikowanych operacji, które zmylą moduł tłumaczenia danych.

Poświęć też czas na poinformowanie zespołu o zmianach — motywacji, przyczynach i serii kroków, które trzeba wykonać. Wybierz zespół „wczesnego wdrażania” złożony z inżynierów doświadczonych w całym cyklu życia oprogramowania, który będzie wzorem dla innych. Znajdź „mistrzów Git”, który będą pomagać osobom mającym trudności. Wprowadzanie małych, zrozumiałych, iteracyjnych zmian pomoże odnieść sukces w tym procesie.

Krok 6. Kopie lustrzane i klastry

Perforce ma prosty, ale skuteczny system tworzenia kopii lustrzanych danych w zdalnych lokalizacjach w celu zmniejszenia efektu opóźnienia. Ma bardziej złożony system uruchamiania zestawu lokalnych kopii lustrzanych do klastrowania tylko do odczytu. Chociaż opóźnienie po prostu nie jest tak dużym problemem dla Git, jeśli prowadzisz działalność na całym świecie, zapoznaj się z Bitbucket Data Center zarówno pod kątem klastrowania, jak i tworzenia kopii lustrzanych, co znacznie skróci czas klonowania dla globalnego zespołu.

Krok 7. Narzędzia ALM

Teraz dobra wiadomość — masz wiele możliwości wyboru dotyczących stosu narzędzi ALM, gdy przejdziesz z Perforce do Git. Prawie każdy programista i narzędzie ALM korzysta z Git, a Bitbucket oczywiście zapewnia doskonałą integrację z Jira i Bamboo. Przechodząc do Git, możesz eksplorować funkcje Bamboo takie jak gałęzie planu, które wykorzystują przepływ pracy gałęzi funkcji.

Krok 8. Definiowanie sukcesu

Jak mierzysz sukces podczas migracji z Perforce do Git? W wielu projektach migracyjnych zbytnio skupiamy się na prawidłowym przebiegu transferu danych, ale to nie jest przydatny wskaźnik z wielu powodów. Prawdopodobnie nigdy nie uzyskasz w Git idealnego odwzorowania historii ze scentralizowanego systemu zarządzania łańcuchem dostaw, takiego jak Perforce.

Bardziej praktycznym podejściem jest weryfikacja w oparciu o ciągłą integrację i ciągłe dostarczanie. Czy po zmianie potoku ciągłej integracji i ciągłego dostarczania z Perforce na Git wszystkie testy nadal kończą się powodzeniem? Czy nadal możesz wdrożyć swoje oprogramowanie? Jeśli wszystkie ważne starsze kompilacje mogą nadal przechodzić przez potok ciągłej integracji i ciągłego dostarczania, nadszedł czas, aby ogłosić sukces.

To wszystko

Teraz wiesz już, dlaczego warto przejść z Perforce na Git, i jak przeprowadzić migrację. Następnym krokiem jest wybranie odpowiedniego rozwiązania Git. Jeśli zmieniasz rozwiązanie do tworzenia gier z Perforce, zobacz, dlaczego twórcy gier uwielbiają Bitbucket.