Migracja do Git z Perforce: dlaczego warto?

Przepływ pracy

Pomijając jednak wszystkie ciekawe dodatki, w narzędziu SCM chodzi przede wszystkim o współpracę — umożliwienie zespołowi programistów pracy nad wspólnym zbiorem plików oprogramowania. System Git oferuje prosty i niedrogi pod względem obliczeniowym model tworzenia gałęzi, który daje swobodę tworzenia wielu ciekawych przepływów pracy. Gałęzie zadań, Git Flow, rozwidlone repozytoria — znajdzie się szybki i łatwy przepływ pracy dla wszystkich zespołów, zarówno dla tworzących oprogramowanie open source, jak i dla profesjonalistów. Do tego zespoły zyskają dostęp do zaawansowanych narzędzi do przeglądu kodu i współpracy.

System Git ułatwia również współpracę ponad granicami firmy, co często jest konieczne w przypadku interdyscyplinarnych projektów programistycznych. Nawet jeśli nie udaje się dostać do współdzielonego repozytorium Git fizycznie za pośrednictwem sieci, narzędzia poprawek i pakietów w Git umożliwiają proste udostępnianie danych.

Z kolei Perforce prowadzi rejestr gałęzi w oparciu o pliki, co odróżnia go od systemu Git, w którym rejestr prowadzony jest w oparciu o commity. Co to oznacza? Cóż, przede wszystkim tworzy ogromną ilość metadanych w bazie Perforce przy każdym utworzeniu gałęzi. W przypadku większych wdrożeń przyczynia się to do problemów z wydajnością w stopniu wymuszającym na wielu administratorach Perforce ograniczenie tworzenia gałęzi.

Zastanówmy się nad tym przez chwilę: za każdym razem, gdy chcesz utworzyć gałąź zadania, aby wypróbować nową funkcję, musisz poprosić o przyznanie uprawnień. Jeśli nie możesz tworzyć gałęzi zadań, możesz przesłać niestabilny kod do gałęzi main lub poczekać, aż wszystko będzie „gotowe” i dopiero wówczas zatwierdzić kod. W efekcie musisz zrezygnować z korzyści, jakie przynosi zastosowanie CI/CD na poziomie gałęzi zadań i szczegółowe śledzenie prac w toku. To z kolei obniża produktywność, ponieważ programiści muszą korzystać z mniej produktywnego przepływu pracy lub zaczynają korzystać z systemu Git „na boku”, a następnie szukają sposobów na ręczne scalanie swojej pracy z powrotem z Perforce.

Wadą rozwiązania Perforce jest nie tylko jego cena, ale także brak możliwości obsługi przepływu pracy preferowanego przez programistów w zastosowanym modelu gałęzi. Gałęzie w Perforce są współdzielone, co oznacza, że nie ma czegoś takiego jak prywatna gałąź zadania z okresową zmianą bazy kodu. Ponadto algorytmy scalania w Perforce są zbyt złożone. Powstały całe artykuły na temat sposobu scalania plików, których nazwa została zmieniona lub atrybuty zmodyfikowane.

A udostępnianie kodu między serwerami Perforce? Wracamy do współdzielenia plików tar bez wspólnej historii. W modelu danych Perforce historia oprogramowania jest traktowana jako unikatowa dla pojedynczego serwera, podczas gdy w systemie Git można z łatwością klonować i udostępniać historię w dowolnym miejscu.

Popularność i społeczność

Odłóżmy na bok konkurencję handlową. Dlaczego zatem Git pokonał Mercurial i innych godnych konkurentów? Nie bez znaczenia jest pewien impet, którego systemowi Git nie można odmówić. Git został opracowany przez Linusa Torvaldsa w celu rozwiązania trudności związanych z rozproszonym tworzeniem oprogramowania w ramach projektu jądra Linux, a obecnie jest on standardowym narzędziem SCM stosowanym w projektach systemów Linux, Android, OpenStack oraz większości innych znaczących projektów open source. Tego właśnie używają wszystkie dzieciaki. Jeśli więc jesteś menedżerem odpowiedzialnym za zatrudnienie, możesz z dużym prawdopodobieństwem założyć, że nowy inżynier potrafi (i będzie chciał) pracować w systemie Git bez konieczności intensywnego szkolenia.

I oczywiście masz możliwość korzystania z ogromnych możliwości, jakie daje tętniąca życiem społeczność open source związaną z systemem Git. Git błyskawicznie się rozwija w kierunku rozwiązywania autentycznych problemów, wprowadzając ważne nowe funkcje, takie jak rozszerzenie Git LFS. Możesz dodać do projektu Git własny kod, jeśli zawiera błąd, który chcesz naprawić, i nie musisz godzić się na ograniczenia komercyjnego produktu, w którym harmonogram i tempo prac narzuca jedna firma. Wystarczy spojrzeć na gamę dostępnych programów klienckich Git: kilka zaawansowanych graficznych interfejsów użytkownika, integracja z Eksploratorem Windows, wtyczki do każdego środowiska IDE i narzędzia deweloperskie.

Graficzne interfejsy użytkownika i narzędzia deweloperskie

Na samym początku swojego istnienia system Git miał pewne braki, jeśli chodzi o graficzny interfejs użytkownika i obsługę narzędzi. Stanowiło to przeszkodę dla użytkowników, którzy woleli interakcje z repozytoriami Git za pośrednictwem interfejsu wizualnego. Szczególnie wykluczało to udział współpracowników słabo zorientowanych w kwestiach technicznych, na przykład artystów pracujących przy grach. W tej grupie odbiorców prawdziwym hitem okazała się wtyczka Eksploratora Windows w Perforce.

Na szczęście te czasy mamy już za sobą. Graficzne interfejsy użytkownika, takie jak Sourcetree, tworzą środowisko obsługiwane za pomocą wskazań i kliknięć, a ponadto istnieje wiele integracji z powłoką dla systemu Git. Rozwiązanie Bitbucket oferuje funkcje przeglądu kodu, scalania i obsługi pull requestów, rozwidlania, przeglądania kodu online oraz mnóstwo innych narzędzi do współpracy. W istocie wszyscy — od analityków danych po agencje kreatywne — organizują społeczności korzystające z otwartej współpracy, jaką umożliwiają Git i Bitbucket.

Twórcy gier to wyjątkowa grupa

Mając to wszystko na uwadze, zastanówmy się, co powstrzymuje niektóre społeczności, takie jak twórcy gier czy badacze pracujący z dużymi zbiorami danych, przed pójściem za modą? Wszystko sprowadza się do rodzaju danych i złożoności organizacji prowadzącej projekt.

Pliki binarne

Twórcy gier, a zwłaszcza artyści, muszą pracować z dużymi obiektami binarnymi, takimi jak tekstury czy zasoby dźwiękowe. Analitycy danych mogą dysponować ogromnymi zbiorami danych zawierającymi miliardy próbek zdarzeń.

Z perspektywy systemu Git stwarza to dwa problemy.

• Takich plików nie da się scalać. Scentralizowany mechanizm blokowania jest tutaj przydatny, a oferuje go Perforce. (Należy przy tym pamiętać, że nawet scentralizowany serwer oferuje mechanizm blokowania jedynie na pojedynczej gałęzi, dlatego korzystanie z tej funkcji wymaga wprowadzenia dużego ograniczenia przepływu pracy).
• Pliki te powodują spowolnienie systemu Git w miarę powiększania repozytorium.

Problem rozmiaru repozytorium w dużym stopniu rozwiązało rozszerzenie Git LFS, które umożliwia systemowi Git obsługę dużych plików fizycznie przechowywanych w innej lokalizacji.

Problem blokowania plików ma dwa oblicza. Z perspektywy zarządzania konfiguracjami oprogramowania Git LFS oferuje lepszy sposób blokowania plików w harmonogramie. Rozszerzenie Git LFS pomaga koordynować blokowanie plików binarnych w wielu gałęziach przy użyciu algorytmu, który daje pewność pracy na najnowszej wersji, niezależnie od tego, w której jest się gałęzi. To otwiera przepływy pracy oparte na gałęziach dla użytkowników pracujących z dużymi plikami binarnymi, w odróżnieniu od modelu blokowania na poziomie jednej gałęzi w Perforce.

Dobrze jest również podejść do kwestii blokowania plików jako problemu związanego z koordynacją. Jeśli zamierzasz przystąpić do pracy nad współdzielonym zasobem, którego nie można scalić, jak przekażesz tę wiedzę wszystkim zainteresowanym stronom? To również jest obszar, w którym mogą zabłysnąć nowoczesne przepływy pracy oparte na pull requestach i współpracy zespołowej w czasie rzeczywistym. Możesz szybko przekazać swoje intencje za pomocą rozwiązania HipChat i sprawdzić, czy do konkretnego pliku nie są przypisane jakieś zaległe prace w toku.

Warto również zastanowić się, jak problem obsługi dużych plików będzie się rozwijał w dobie Big Data. Aby przetestować zadanie analityczne na zbiorach Big Data, potrzebny jest zbiór danych o rozmiarze kilku terabajtów. Zapomnij o dowolnym systemie SCM — ten projekt jest testowany i uruchamiany w systemie plików zgodnych z modelem Big Data. Tutaj potrzebny jest system CI/CD, który pozwoli skoordynować bardziej złożony pipeline obejmujący artefakty funkcjonujące w systemie HDFS lub S3. To z kolei prowadzi nas do kolejnego tematu.

Duże projekty

Tworzenie gier jest klasycznym przykładem projektu oprogramowania z wieloma modułami lub komponentami — silnikiem gry, interfejsem użytkownika, grafiką statyczną, renderingami wideo i tak dalej. Perforce jako monolityczne scentralizowane repozytorium może obsługiwać wszystkie te moduły na jednym serwerze i pozwala użytkownikom wybierać części do pobrania do własnej przestrzeni roboczej.

Jednak ta zaleta jest obecnie w dużym stopniu dyskusyjna. Nowoczesne systemy Git, takie jak Bitbucket, umożliwiają łatwiejsze zarządzanie wielomodułowymi narzędziami Git, takimi jak moduły podrzędne i drzewa podrzędne. Co ważniejsze, duże projekty, takie jak Android, pokazały, w jaki sposób zarządzać skomplikowanym projektem przy użyciu bardziej ogólnych narzędzi złożonych z wielu elementów. Wiele z tych wniosków wykorzystano w nowoczesnych narzędziach CI/CD, takich jak Bamboo i Bitbucket Pipelines, które umożliwiają koordynowanie złożonych przepływów pracy opartych na ciągłej integracji, modelowanie zależności między projektami i zarządzanie artefaktami między projektami.

Trend ten jest w dużej mierze zgodny z leżącą u podstaw Git (i *nix) filozofią tworzenia narzędzia, które bardzo dobrze radzi sobie z jednym zadaniem. Ciągła integracja i ciągłe dostarczanie (CI/CD) to praktyka sama w sobie obejmująca narzędzia ułatwiające zrozumienie przepływów pracy związanych z kompilacją i wydawaniem. Poza tym praktyka ta jest zgodna ze zbiorem nowoczesnych najlepszych praktyk w dziedzinie tworzenia oprogramowania, w których dąży się do korzystania z niezależnych mikrousług, a nie monolitycznych projektów.

Kolejne kroki

W grupie zwolenników przejścia z Perforce na Git zdecydowanie widać tendencję rozwojową, a Git i nowoczesne narzędzia CI/CD są teraz przygotowane do obsługi nawet największych i najbardziej złożonych prac programistycznych. Zespół Perforce opracował nawet narzędzie o nazwie Git Fusion, które umożliwia wyodrębnienie części centralnego repozytorium Perforce jako repozytorium Git.

Choć wysiłek związany z opracowaniem narzędzia Git Fusion zasługuje na uznanie, niestety nałożenie systemu Git na scentralizowany system SCM okazało się niełatwym zadaniem. Próba połączenia modeli użycia może szybko doprowadzić do uszkodzenia widoku danych jednego z systemów. Jeśli nie łączysz modeli użycia, trudno dostrzec zalety wstawienia komercyjnego scentralizowanego backendu za system Git. Jak widzieliśmy, trend jest raczej przeciwny i polega na dążeniu do wzbogacenia systemu Git o tych kilka pozostałych elementów scentralizowanego systemu SCM, jakie są jeszcze przydatne.

Jeśli korzystasz z Perforce przy tworzeniu dowolnego oprogramowania lub gry, prawdopodobnie zastanawiasz się (z niecierpliwością), jak przeprowadzić migrację do systemu Git. Tylko jak to zrobić? I czy zmiana jest warta kosztu przeniesienia? Tym właśnie zajmiemy się w kolejnym artykule.