Scroll to top
en pl

Ukryte koszty zarządzania Gitem


Armin Orlik - 27 lipca 2017 - 0 comments

Cena Wolności

Najlepszą cechą oprogramowania open source jest zapewne wolność. Git jest tutaj klasycznym przykładem. Możesz go pobrać za darmo i używać w dowolny sposób, masz też możliwość manipulacji i przerabiania kodu źródłowego.

Jest jednak pewien haczyk. Wolność nie jest darmowa. Tę frazę najczęściej można usłyszeć w obszarze polityki, jako wyraz uznania wobec ceny (czasami najwyższej) jaką wielu w historii musiało zapłacić, aby zapewnić wolność pozostałym. Niespodziewanie, okazuje się ona równie prawdziwa względem oprogramowania open source, a Gita w szczególności.

Celem tego artykułu jest naświetlenie pewnych ukrytych kosztów Gita, tak aby być ich w pełni świadomym przed wdrożeniem i w przyszłości uniknąć niepotrzebnych niespodzianek. Koniec końców, Git jest dobrym narzędziem do wielu zadań, ale nie nadaje się do każdego. Możemy łatwo wpaść w pułapkę pojęcia “darmowy” i nie zauważyć ukrytych kosztów. Wówczas, wszelkie zmiany mogą okazać się nie tylko konieczne, ale i bardzo drogie.

Koszty Skali

W branży komputerowej mówimy z reguły o skalowalności w trzech wymiarach: pionowym, poziomym, i geograficznym. Nie będziemy analizować szczegółowych różnic, skupimy się jedynie na podstawach. W skalowalności pionowej chodzi o uzyskanie maksimum z istniejących zasobów, w horyzontalnej o rozproszenie pracy na większą ilość zasobów, a skalowalność geograficzna łączy zasoby i użytkowników rozproszonych po całym globie.

Git, niestety, nie był projektowany z myślą o jakiejkolwiek skalowalności. Pierwotny Git nie wykorzystuje maksymalnie hardware’u, więc rozszerzanie o kolejne procesory lub kości pamięci nie pomoże Ci w uzyskaniu pionowego efektu skali.  Większość serwisów hostingowych próbuje sobie z tym poradzić poprzez nałożenie webowego front-edu na pierwotnego Gita, pozostawiając rozwiązanie problemu samej naturze aplikacji webowych, które potrafią asynchronicznie przetworzyć większą ilość zapytań. Ten sposób jest tak dobry jak system plików którego używamy, gdyż Git w całości się na nim opiera.

Niestety, jego unikatowy, innowacyjny system przechowywania (grupowanie zasobów w plikach w oparciu o wartości hashów SHA-1), choć świetny do deduplikacji zbiorów, pozostawia wiele do życzenia gdy repozytoria zwiększają rozmiary. Pewne komendy Gita wymagają obliczania (w wielu wypadkach ponownego) wartości hashy, co staje się coraz wolniejsze gdy wzrasta ilość contentu. Liczenie hashy jest skomplikowane, w przypadku pracy z dużymi plikami binarnymi wręcz patologicznie.

Społeczność Gita odpowiedziała na ten problem tworząc szereg nakładek i zmian workflow, tak aby pozostawić duże pliki poza systemem kontroli wersji, łącząc je w robocze foldery. Narzędzia takie jak git-annex i Git LFS potrafią uprościć ten proces, ale korzystanie z  kolejnych narzędzi i dzielenie contentu stoi w sprzeczności z Agile-ową zasadą “pojedynczego źródła prawdy”.

Co więcej, serwisy hostingowe Gita z reguły nakładają dodatkowe opłaty za ich używanie i korzystanie z baz. Możesz zawsze próbować samemu udźwignąć obciążenie związane z nakładkami, ale tak czy owak będzie to dodatkowy ukryty koszt adaptacji Gita dla wielu pracujących z dużymi plikami.

Co gorsza, podstawowy problem pozostaje nierozwiązany. Nawet gdy użyjesz narzędzi umożliwiających przechowywanie dużych plików binarnych poza Twoimi repozytoriami, mają one nadal tendencję do wzrostu i podziału. Zjawisko to jest tak powszechne, że wymyślono do jego opisania termin “Git sprawl”. W rezultacie, Git zmusza Cię do horyzontalnego skalowania repozytoriów tylko po to, aby zapewnić akceptowalną wydajność.

Jest to kolejne źródło znaczących, ukrytych kosztów związanych z wydajnością i produktywnością, zwłaszcza podczas pracy z systemami continous integration. Unifikacja wielu repozytoriów podczas buildu obciąża zespoły DevOps, i może oznaczać konieczność zakupu dodatkowych serwerów, zdolnych do obsłużenia wszystkich równoczesnych pull requestów. Widzieliśmy jak klienci z terabajtami contentu unikali Gita dokładnie z tego powodu: jeśli pojedynczy terabajt ma oznaczać utrzymywanie tysięcy repozytoriów w celu zapewnienia akceptowalnej wydajności, to kto chciałby się tym wszystkim zajmować?!  

W kwestii skalowania geograficznego, dobrą wiadomością jest dość efektywne podejście Gita, zarówno pod względem obliczania co należy transferować, jak i protokołów sieciowych do samego transferu danych. Zła wiadomość to fakt, że nie oferuje on żadnego sposobu na ujednolicenie pracy wielu zespołów pracujących równocześnie na wielu repozytoriach. Mamy więc dylemat: hostowanie ich w pojedynczej lokalizacji przeszkadza wszystkim znajdującym się poza nią, poprzez lagi i kiepską przepustowość, lub zawodne łącza WAN, zaś hosting w wielu lokalizacjach znacznie komplikuje proces składania ich z powrotem w całość i robienia buildów na jej podstawie.

Warto abyś wiedział o istnieniu jeszcze trzech, innych rodzajów ukrytych kosztów:

  • niełatwy do rozwiązania problem replikacji/mirrorowania contentu,
  • konieczność adaptacji i ścisłego trzymania się określonego workflow i praktyk branchowania,
  • rozwiązywanie – często samodzielne – problemów związanych z HA/DR. Nietrudno sobie wyobrazić, że utrzymywanie dużych plików poza repozytorium tylko komplikuje ten proces, skutkując kolejnymi ukrytymi kosztami związanymi z powyższymi trzema problemami.

Koszty użytkowania

Kolejnym, często pomijanym kosztem adaptacji i użytkowania Gita jest konieczność nauki. Patrząc, jak powszechnie wdraża się dzisiaj Gita, można wyciągnąć błędny wniosek, że wystarczy go tylko pobrać i można zaczynać pracę, a jest dokładnie na odwrót. Ostatnie badanie przeprowadzone przez GitLab ujawniło, że developerzy jako ogół uważają naukę Gita za trudne zadanie, a nie mniej niż 40% wskazuje ją jako największe wyzwanie przy adaptacji.

Grupa docelowa badania również pozwala na wyciągnięcie pewnych wniosków. Przecież jeśli developerzy mają problemy z Gitem, jako osoby o wysokich umiejętnościach technicznych, przyzwyczajone do nauki nowych, skomplikowanych narzędzi na codzień, to jak mają sobie z nim poradzić mniej techniczni pracownicy? Unifikacja pracy w którą wkład ma wiele dyscyplin, takich jak artyści, specjaliści od animacji, autorzy, i wielu innych, to często spotykane wyzwanie w erze DevOps, a stopień trudności nauki Gita nie ułatwia sprawy.

Wręcz przeciwnie, Git nie jest narzędziem do wersjonowania przyjaznym dla początkujących, gdyż oferuje zaawansowane funkcje, i wymaga znajomości swojego modelu danych aby unikać problemów. Na przykład, źle użyte polecenie rebase może zniszczyć pracę na konkretnym branchu. Co prawda większość serwisów hostingowych już nie pozwala żeby forced-push przeszkodził zespołom pracującym na wspólnych branchach, ale to tylko obroni innych członków zespołu przed problemami; użytkownika, który popełnił błąd, i tak czeka wiele pracy, aby naprawić swoje lokalne repo.

Na szczęście, istnieje kilka sposobów na ułatwienie nauki Gita, a nienajgorszym z nich jest używanie jednego z dostępnych GUI. Git ma co prawda kilka własnych narzędzi graficznych, ale wielu użytkowników preferuje jednak te zewnętrzne. Pamiętaj o tym, by właściwie oszacować umiejętności mniej technicznych członków zespołu, i wyposażyć ich w odpowiednie narzędzia, ewentualnie proste w obsłudze wtyczki do aplikacji, których używają na codzień.

Ta selekcja właściwych interfejsów dla każdego, która musi uwzględniać ich preferowany workflow, i nie przeciążać ich technicznych możliwości, to kolejny, często niedostrzegany, koszt adaptacji Gita. Najlepsze i najprostsze narzędzia rzadko są darmowe, a te koszty mogą się szybko nawarstwić patrząc w skali roku, lub też użytkownika.

Co więcej, nie wspomnieliśmy jeszcze o najbardziej podstawowych zabezpieczeniach. Git był projektowany, aby dostarczyć repozytoria w modelu wszystko-w-jednym: wszyscy dostają każdy plik i folder, i mogą robić wszystko na co pozwala system. Ale czy na pewno chcesz, by każdy miał dostęp do każdego pliku i folderu, z których składa się Twoja własność intelektualna? W realiach wielu organizacji i projektów, podejście pierwotnego Gita jest po prostu zbyt naiwne.

Serwisy hostingowe Gita często umożliwiają “zabezpieczanie” repozytoriów poprzez różne uprawnienia, a nawet chronią poszczególne branche, dopuszczając do pushowania tylko konkretne grupy. Niewiele jednak oferuje kontrolę do pojedynczego pliku, i uprawnienia granularne jakie znamy z centralnych systemów. Każdy, kto ma dostęp do repo, ma z reguły dostęp do wszystkiego w środku, co oznacza że restrykcje dostępu do własności intelektualnej wiążą się z dzieleniem repozytorium, wzmacniając tym samym zjawisko “Git sprawl”.

To z kolei oznacza kolejny ukryty koszt, coraz ważniejszy w czasach gdy outsourcing jest normą. Żonglowanie pomiędzy koniecznością ograniczenia dostępu do contentu stanowiącego własność intelektualną, a umożliwieniem pracy zespołom i konsultantom z outsourcingu może znacząco wpłynąć na wydajność, i jaskrawo wpasowuje się we wcześniejszą dyskusję o skalowaniu geograficznym.

Podsumowanie

Git zapewnia wolność, ale jego adaptacja i długotrwałe użytkowanie nie są tanie. Wręcz przeciwnie, koszty Gita tylko rosną w czasie, w wielu kierunkach. Prawdę mówiąc, Git to świetne narzędzie dla małych zespołów pracujących nad niewielkimi projektami. Ale gdy te zespoły odniosą sukces, nagle urosną, i zaczną się zajmować dużymi projektami, często zaskakują je ukryte koszty, które tu wyliczyliśmy. Jednak na tym etapie, zmiana systemu na lepszy często jest już zbyt trudna i zbyt droga.

W przeciwieństwie do Gita, systemu Perforce Helix nie da się przerosnąć. Nie zwalnia przy pracy z dużymi lub zbyt licznymi plikami, zapewnia szeroką gamę aplikacji klienckich i wtyczek, które zunifikują wkład wszystkich pracowników, zapewnia dużo prostsze modele danych i workflow, zabezpiecza content aż do poziomu pojedynczego pliku poprzez elastyczny zestaw uprawnień, i nigdy nie zniszczy Twojego sukcesu ukrytymi kosztami. Helix oferuje również bardziej zaawansowane funkcje rozproszone (DVCS) niż Git, i ma zdolność integracji z szeroką gamą narzędzi używanych w branży. Co więcej, jest darmowy dla małych zespołów i udostępnia prostą wersję próbną – wraz ze wsparciem dla tych developerów, którzy nadal wolą Gita.

Jakiego systemu byś nie wybrał, nie uwolnisz się od kosztów, mierzonych w taki lub inny sposób. Jedyny wybór jaki masz, to czy płacić z góry, czy później, w postaci frustracji, utraty produktywności, niespodziewanych kosztów gotówkowych, być może także czasu i wysiłku związanego ze zmianą systemu, a nawet komplikacji i strat związanych z wyciekiem danych. Może lepiej zatem wypróbować Helixa, i uniknąć tego wszystkiego?

Related posts