A step-by-step guide to migrating from Perforce to 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:
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:
materiały pokrewne
Jak przenieść pełne repozytorium Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
- 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.
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project 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/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in 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.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.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
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/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.
Step 6: Mirrors and clusters
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.
Step 7: ALM tools
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.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
