Scroll to top
en pl

Git w przedsiębiorstwie – siedem wskazówek jak odnieść sukces


Armin Orlik - 20 lipca 2017 - 0 comments

Popularność Gita w projektach open source, a także w innych małych i średnich przedsięwzięciach, sprawiła że coraz częściej jest on wykorzystywany w segmencie enterprise. Jednak sprawne wdrożenie Gita w tym obszarze nie jest ani łatwe, ani oczywiste. W praktyce, adaptacja Gita oznacza trudne kompromisy pomiędzy preferencjami dewelopera, a potrzebami przedsiębiorstwa. Niniejszy przewodnik przedstawia najistotniejsze rozważania związane z używaniem Gita w przedsiębiorstwie, oraz dostarcza praktycznych porad wdrożeniowych.

Wstęp – cytat Gartner, Inc.

„Z perspektywy zespołu, praca z rozproszonym systemem kontroli wersji (DVCS) jest bardziej skomplikowana, niż praca z systemem centralnym. To właśnie poziom skomplikowania jest źródłem większości obecnych barier, przeszkadzających w szerszym użyciu takich systemów”.

Workflow

Najoczywistszym powodem, dla którego wykorzystuje  się Gita, jest upodobanie developerów do jego rozproszonego przepływu pracy, nawet jeśli rzadko używa się modelu całkowicie rozproszonego. Developerzy często muszą zmieniać wątki, a lekkie, lokalne branchowanie, jakie wspiera Git, bardzo w tym pomaga. To właśnie sposób obsługi branchy jest ważną, wyróżniającą cechą Gita.

Ale jak zarządzać złożonością, jaką wprowadza Git, gdy spojrzy się na temat z perspektywy szerszej, niż pojedynczy komputer? Kto ma decydować o ostatecznej strukturze gałęzi przed jej wydaniem? Jak należy dzielić się gałęziami eksperymentalnymi z kolegami? Gdzie należy zrobić rewizję? Kiedy zawartość tych gałęzi powinna być zmerge’owana na powrót z głównym branchem? I jak to w ogóle zrobić, skoro społeczność Gita pozostaje podzielona dwubiegunowo, na zwolenników operacji branch i rebase?

Propozycja Git-flow to jeden ze sposobów, choć nie będzie on idealny dla wszystkich zespołów. Narzędzia takie jak GitSwarm, GitHub, GitLab, lub Atlassian Stash wprowadzają proste procesy skupione wokół operacji pull request, które mogą dostarczyć pewnych odpowiedzi.

Najlepszym momentem aby rozwiązać te problemy jest czas przed wdrożeniem Gita przez zespoły, ponieważ próby zmian w procesie już po rozpoczęciu pracy, oraz aktualizacja historii rewizji, to dosyć skomplikowana sprawa. .

Workflow – dobre praktyki

  • Określ swoją strategią rozgałęziania, z wyraźnymi etapami, i jasnymi warunkami przejścia. Najlepiej zautomatyzuj przepływ kodu tak bardzo jak to tylko możliwe.
  • Określ rewizję jako integralną część swojej strategii. Interdyscyplinarna kolaboracja jest kluczowa w nowoczesnym rozwoju produktu.
  • Wyposaż wszystkie scenariusze  w narzędzia dostosowane do ich konkretnych potrzeb, aby zmaksymalizować produktywność i łatwość użytkowania.

Zasoby

Popularna zasada obowiązująca przy pracy w metodykach zwinnych głosi, że należy przechowywać całą własność intelektualną w tym samym miejscu, „jedynym źródle prawdy”. Okazuje się jednak, że interdyscyplinarny charakter zespołów i wymagań projektowych lawinowo zwiększa liczbę i rozmiar zasobów w typowym projekcie. Kod źródłowy to często jedynie kropla w cyfrowym morzu w porównaniu z dokumentacją, grafiką, modelami, dźwiękiem, wideo, a nawet całymi środowiskami maszyn wirtualnych (VM) służącymi do testów i wdrożeń.

Ten rodzaj ekspansji oznacza poważne wyzwanie przy adaptacji Gita w przedsiębiorstwie, ponieważ jego mechanizmy wewnętrzne ograniczają maksymalny praktyczny rozmiar repozytorium do gigabajta albo dwóch. Nawet repozytoria daleko mniejsze niż ten limit mogą mieć problemy z wydajnością, jeśli typ i rozmiar zasobów oraz wykonywane komendy temu sprzyjają. Wykonanie choćby prostej komendy blame na repozytorium z dużymi zasobami binarnymi może boleśnie unaocznić ten problem.

Co więcej, tego rodzaju zasoby są tworzone przez projektantów lub artystów, którym brakuje umiejętności technicznych, w związku z czym nie użyją oni wiersza poleceń Gita, nawet jeśli mogłoby to pomóc im w pracy. Twoja strategia zarządzania Gitem powinna określać, jak współpracownicy będący technicznymi laikami mają przechowywać swoją pracę, jak zarządzać tymi plikami razem z kodem źródłowym w Gicie, i jak zebrać razem właściwe wersje wszystkich plików w Twoim systemie produkcji i wydawania.

Najpopularniejsze sposoby zarządzania dużymi zasobami cyfrowymi to przeniesienie dużych plików poza repozytorium, lub podzielenie zasobów pomiędzy kilka repozytoriów, magicznie połączonych przez DevOps-ów dla celów produkcyjnych, testowania, wydawania, i innych zadań. Narzędzia takie jak git-annex i Git LFS mogą pomóc przenieść zasoby cyfrowe poza repozytorium, podczas gdy wpływanie na moduły zależne Gita, wraz z zestawem autorskich skryptów, umożliwia ujarzmienie zjawiska rozwlekania zasobów pomiędzy repozytoriami (tzw. Git sprawl). Takie podejście może jednak powodować kolejne problemy, związane z tworzeniem kopii zapasowych, czy też dystrybucją treści pomiędzy oddziałami firmy. Jeśli to tylko możliwe, przedsiębiorstwo powinno szukać systemu umożliwiającego czerpanie korzyści z rozproszonej kontroli wersji (DVCS), ale przechowującego wszystkie zasoby w jednym miejscu.

Zasoby – dobre praktyki

  • Przechowuj wszystkie zasoby w jednym miejscu, najlepiej w jednym narzędziu do kontroli wersji. Jeśli tego nie zrobisz, a zdecydujesz się używać Gita, pomyśl o adaptacji „monorepo” (pojedynczego, dużego repozytorium – ze wszystkimi opisanymi wcześniej konsekwencjami używania takiego repozytorium z Gitem), zamiast opierać się na narzędziach, które podzielą Twoją własność intelektualną.
  • Używaj takiego pakietu zarządzania Gitem, który poradzi sobie z wszystkimi plikami, w tym z zasobami cyfrowymi – nie tylko z kodem źródłowym.
  • Określ strategię archiwizacji starszych zasobów, dopasowaną do strategii rozgałęziania, aby utrzymywać porządek i łatwość użycia repozytoriów.

Continuous Delivery

Przepływ pracy i typ zasobów tworzonych przez Twoich pracowników może być różny, ale końcowy produkt zawsze musi być przetestowany i zintegrowany z maksymalnym wykorzystaniem automatyzacji. Automatyzacja w połączeniu z architekturą Gita może znacząco obciążyć system, co oznacza że wcześniejsze planowanie jest konieczne, aby uzyskać sensowną wydajność systemów continuous delivery.

Powszechnie używaną praktyką w CD jest build i testowanie na aktualnej kopii wszystkich plików. Jednak w przypadku używania Gita w przedsiębiorstwie, można w ten sposób łatwo przeciążyć serwery. Dzieje się tak z dwóch powodów. Po pierwsze, tak jak większość systemów rozproszonych (DVCS), Git domyślnie pobiera wszystkie wersje plików podczas operacji klonowania. Po drugie, Git nie wspiera klonowania wąskiego (tj. przy użyciu tylko potrzebnych plików, zamiast wszystkich). Podsumowując, przy klonowaniu repozytorium Git, dostajesz domyślnie wszystkie wersje wszystkich plików.

Powyższe problemy z reguły nie mają znaczenia w projektach małych, średnich, i open source, ale mogą okazać się przeszkodami nie do pokonania w dużych projektach spotykanych w przedsiębiorstwach. Sama ilość operacji łączenia przy dużej ilości gałęzi produkcyjnych może okazać się przysłowiową “skórką od banana” na drodze projektu. Git zachęca deweloperów do rozgałęziania wszystkich zadań lub feature’ów, ale synchronizacja pracy w obu kierunkach może być trudna dla dużych zespołów pracujących z wieloma plikami.

Continuous Delivery – dobre praktyki

  • Używaj klonowania płytkiego aby otrzymać tylko ostatnie wersje plików, i staraj się używać systemu zarządzania Gitem który wspiera klonowanie wąskie. Dzięki temu znacząco zmniejszysz obciążenie serwera.
  • Wybierz właściwy cykl buildów dla Twoich projektów. Build raz na godzinę lub dzień, zamiast przy każdym wgraniu nowych plików, może być konieczny gdy używasz Gita.
  • Zautomatyzuj łączenie kodu i zwiększ jego częstotliwość do maksimum. W ten sposób będziesz mógł wykryć problemy z integracją zanim się nawarstwią, i zapchają przepływ kodu.

Niezawodność

Nawet najlepsze narzędzie jest bezużyteczne, gdy nie działa. To stwierdzenie jest prawdziwe zwłaszcza w warunkach przedsiębiorstwa, które często musi pracować przez całą dobę, na całym świecie. Git został zbudowany z myślą o prostych systemach plików, a większość systemów zarządzania Gitem jest zbudowana bezpośrednio na jego podstawowej wersji. Spełnienie wymagań przedsiębiorstwa dotyczących wysokiej dostępności i odtwarzania awaryjnego (disaster recovery) może stanowić duże wyzwanie.

Większość systemów zarządzających Gitem oferuje usługi takie jak tworzenie kopii zapasowych i snapshotów, co jest dobrą pierwszą linią obrony. Niektóre systemy zwiększają poziom dostępności dzięki czuwającym maszynom wirtualnym, przy użyciu różnych środków do odzwierciedlania zmian pomiędzy systemami plików, czy też zamiany serwerów, jeśli zajdzie taka konieczność. Nie zmienia to jednak faktu, że jeśli potrzebujesz skalowalności typu dial-a-load w połączeniu z wysoką dostępnością, Twój wybór jest znacznie ograniczony.

Pamiętaj też o tym, że o ile sklonowanie repozytorium dla bezpieczeństwa może wydawać się łatwe, to w przypadku Gita będziesz klonować całe repozytorium. To podejście nie stanowi problemu w małych i średnich projektach, jednak duże projekty zjadają przepustowość sieci, dyski, i czas. Jeśli Twoje zasoby mierzy się czymś większym niż megabajty, musisz szczegółowo przyjrzeć się poziomowi niezawodności, jaki oferuje Twój system zarządzania Gitem.

Niezawodność – dobre praktyki

  • Kopie zapasowe są dobre, ale plan odtwarzania awaryjnego jest lepszy. Stwórz taki plan, bilansujący akceptowalne straty z kosztami, i regularnie go sprawdzaj.
  • Podczas wyboru systemu zarządzania Gitem, szukaj takiego, które zapewni zarówno klastrowanie, jak i wysoki poziom dostępności, dzięki czemu wszyscy będą mogli pracować nawet gdy padnie sprzęt.

Bezpieczeństwo

Czysty Git zapewnia jedynie ograniczony poziom bezpieczeństwa, oferując solidne uwierzytelnianie, i kompletnie ignorując autoryzację. Innymi słowy, obchodzi go kim jesteś, ale pozwala Ci zrobić z plikami co zechcesz. To podejście świetnie się sprawdza jeśli chcesz tylko upewnić się, że każdy wgrywający zmiany jest tym, za kogo się podaje, ponieważ jego tożsamość jest weryfikowana poprzez cyfrowe podpisy.

Co jednak w sytuacji, gdy chcesz ograniczyć dostęp do konkretnego repozytorium? Do konkretnego brancha? Może do pliku zawierającego tajemnice przedsiębiorstwa? Git nie oferuje niczego co odpowiadałoby tym potrzebom, co stanowi główny powód istnienia tylu systemów zarządzania Gitem. Nie są one jednak na równym poziomie jeśli chodzi o zapewnienie bezpieczeństwa.

Systemy zarządzania Gitem z reguły oferują łatwe tworzenie użytkowników i grup, i ograniczanie dostępu do projektu (czytaj: repo) tymi sposobami. Co więcej, dostarczają z reguły niewielkie zestawy ról do których możesz przypisać różne pozwolenia. Niektóre (np. GitLab) rozszerzają pozwolenia również na gałęzie, umożliwiając ograniczenie dostępu tym, a nie innym użytkownikom.

Jeśli potrzebujesz czegoś więcej (np. szczegółowych uprawnień na poziomie folderu/pliku), dużo trudniej o rozwiązanie. Najlepsze z nich będą oferować zróżnicowany poziom monitoringu i śledzenie wzorów użytkowania.

Pomyśl także o swoich potrzebach dotyczących audytu oraz rejestrowania operacji. W środowisku o podwyższonym poziomie bezpieczeństwa lub regulacji może istnieć konieczność prowadzenia stałego zapisu, określającego kto dokonał zmian, kiedy, i w jakim celu. Standardowy Git pozwala na sporą elastyczność przy nadpisywaniu historii, albo nawet zupełnym ukrywaniu zmian. Jeśli możliwość pełnego audytu jest dla Ciebie istotna, szukaj narzędzia do kontroli wersji które oferuje niezawodny, bezpieczny zapis.

Bezpieczeństwo – dobre praktyki

  • Upewnij się że Twoja struktura branchy nie tylko pasuje do workflow’a, ale również dzieli zasoby zgodnie z potrzebami zabezpieczeń.
  • Wybierz taki system zarządzania Gitem, który dostarcza możliwość kontroli dostępu o maksymalnym rozdrobnieniu, aby sprostać wymogom bezpieczeństwa.
  • Jeśli gałęzie nie wystarczą, zawczasu zorganizuj zasoby w taki sposób, aby krytyczne ze względów bezpieczeństwa pliki trzymać razem, co ułatwi później definiowanie ograniczeń dostępu.
  • Wybierz taki system zarządzania Gitem, który zapewnia na czas aktywne monitorowanie akcji użytkownika, aby oznaczyć i zaraportować budzące wątpliwości zachowanie, zanim zostaniesz narażony na utratę własności intelektualnej.

Zarządzanie repozytoriami

Potrzeba posiadania systemu zarządzania repozytoriami zależy w dużym stopniu od ograniczeń Twojego systemu zarządzania Gitem. Jeśli wybierzesz system, który nie radzi sobie z zasobami cyfrowymi, dużą ilością plików, czy też dużym całkowitym rozmiarem repozytorium, to Git sprawl (rozwlekanie zasobów pomiędzy repozytoriami – przyp. red.) będzie się pojawiać.

Możesz także łatwo wywołać Git sprawl jeśli Twój proces opiera się mocno o buildy z komponentów. Duża liczba niezależnie tworzonych i wersjonowanych komponentów może spowodować problemy z modułami zależnymi Gita, jeśli Twój system zarządzania nie oferuje innego mechanizmu. Git sam w sobie raczej ułatwia mapowanie zewnętrznych repozytoriów między sobą, ale trzeba wcześniej poradzić sobie z doborem dedykowanych narzędzi, metodyk, i zawarciem pewnych kompromisów.

Niezależnie od przyczyny, im bardziej podzielisz swoje zasoby, tym więcej problemów napotkasz przy ich łączeniu w celach produkcyjnych, testowych, i dla innych zadań. Eksplozja liczby repozytoriów będzie oznaczać ból głowy dla DevOps-ów w pełnym wymiarze godzin, dlatego trzeba ostrożnie je rozplanować, a potem utrzymywać.

Zarządzanie repozytoriami – dobre praktyki

  • Weź pod uwagę czas zespołu DevOps, jaki można przeznaczyć na zarządzanie repozytoriami, gdy będziesz prześwietlał swoje zasoby i dobierał rozwiązanie.
  • Jeśli to w ogóle możliwe, zbadaj możliwość wykorzystania narzędzi i technik “zarządzania” wysokopoziomowymi komponentami.
  • Używaj systemu zarządzania Gitem który pozwoli maksymalnie unikać zjawiska Git sprawl, albo przynajmniej zakulisowo zajmie się tym problemem.

Widoczność

Ostatni przystanek wycieczki po potrzebach przedsiębiorstw to kolejna kwestia, którą Git sam w sobie kompletnie ignoruje, a systemy zarządzania niewiele mu pomagają: potrzeba pełnej, transparentnej widoczności wszystkich etapów linii produkcyjnej. Większość systemów zarządzania Gitem zapewnia dashboardy zestawiające wszystkie projekty, dashboardy do indywidualnych projektów, a nawet garść przydatnych statystyk. Wiele z nich dostarcza także proste narzędzie do śledzenia problemów, lub zdolność do integracji z zewnętrznymi narzędziami do zarządzania cyklem życia aplikacji (ALM).

Jeśli jednak nie wybierzesz dostawcy który zapewni również pozostałe elementy kompletnego rozwiązania, to prawdopodobnie będziesz musiał samemu tworzyć wtyczki, skrypty, i inne mechanizmy integracyjne. Wspomniany wcześniej Git sprawl komplikuje sprawę jeszcze bardziej – z oczywistych powodów, łatwiej analizować dane z monorepo, niż z setek, albo tysięcy repozytoriów.

„System zarządzania Gitem dla przedsiębiorstw, który oferuje istotne zalety systemu rozproszonego (DVCS) – dobre łączenie (gałęzi – przyp.red.), tryb offline, i dobrą współpracę – wraz z zabezpieczeniami i repozytorium centralnym (CVCS), rozwiąże większość pozostałych problemów związanych z użyciem modelu DVCS”. – Gartner, Inc.

Widoczność – dobre praktyki

  • Dokładnie określ swoje priorytety informacyjne i najważniejsze metryki. Kieruj się nimi wybierając system zarządzania Gitem.
  • Pomyśl, do jakiego stopnia rozwiązanie, które wybierasz, wywoła Git sprawl. W razie potrzeby, rozważ dobór narzędzi i technik do agregacji danych.
  • Wybierz dostawcę, który oferuje coś więcej niż tylko zarządzanie Gitem, zwłaszcza jeśli potrzebujesz dedykowanych metryk, lub szerokiego wsparcia dla integracji z innymi narzędziami.

Wnioski

Rozpatrzyliśmy siedem kluczowych aspektów, gdzie Git może być problemem w przedsiębiorstwie. Najlepszą opcją dla Twojej firmy może być alternatywa wobec Gita, dopasowana do jej potrzeb, lecz nadal oferująca możliwości kochane przez deweloperów.

Rynek oferuje kilka takich narzędzi, wśród których liderem jest Perforce Helix. Jeśli jednak zdecydujesz się na wdrożenie Gita, dobre praktyki zawarte w tym poradniku powinny pomóc Ci w planowaniu i wyborze optymalnego systemu zarządzania Gitem, minimalizując ilość problemów w dłuższym horyzoncie czasowym. Podsumowując, przyjrzyj się dobrze swoim procesom, zasobom, i potrzebom, zanim bez zastanowienia zdecydujesz się na wdrożenie Gita w swoim przedsiębiorstwie.

Jesteś zainteresowany systemami kontroli wersji? Dowiedź się więcej, weź udział w webinarze odnośnie popularnych rezpozytirów – Perforce i Git.  Więcej informacji znajdziesz klikając tutaj.

Related posts