Rzucanie światła na strategie repozytorium kodu

Mono-repo i multi-repo stanowią dwie odmienne strategie w dziedzinie hostowania i zarządzania kodem za pomocą systemu Git. W niniejszym opracowaniu szczegółowo przeanalizujemy obie te metody, zwracając uwagę na ich atuty oraz słabe strony.

Wprowadzenie

Współczesne projekty w większości korzystają z Git jako platformy do zarządzania i przechowywania kodu. Git stał się powszechnie przyjętym standardem w zakresie zarządzania rozproszonym kodem źródłowym, kontroli wersji oraz współpracy, niezależnie od lokalizacji geograficznej. Jego szybkość i efektywność są niepodważalne. W kontekście hostingu i zarządzania kodem Git wyróżniamy dwa główne podejścia:

Zanim przejdziemy do szczegółowej analizy tych strategii, warto wyjaśnić, czym właściwie jest repozytorium.

Czym są repozytoria?

Repozytorium, często skracane do repo, to zbiór wszystkich katalogów i plików składających się na dany projekt. Zawiera ono również informacje o użytkownikach, osobach zaangażowanych w projekt oraz maszynach, na których kod jest rozwijany.

Dane w repozytorium podlegają kontroli wersji, co umożliwia śledzenie zmian i powrót do wcześniejszych stanów projektu. Repo może być własnością pojedynczej osoby lub zespołu.

Git to w istocie system repozytoriów. Mogą być one publiczne, prywatne lub wewnętrzne, w zależności od potrzeb projektu. Usługa GitHub to platforma hostingowa dla repozytoriów Git, która dodatkowo oferuje przyjazny interfejs użytkownika.

Git udostępnia kontrolę wersji oraz mechanizmy do udostępniania kodu. Unikalną cechą systemu jest możliwość skopiowania całego repozytorium do lokalnego systemu, co pozwala programistom na dokonywanie modyfikacji nawet bez bezpośredniego dostępu do zapisu w projekcie (tzw. forking).

Ponadto, programista może następnie przesłać „prośbę o scalenie” (pull request) do właściciela projektu, aby wprowadzić swoje zmiany do głównej gałęzi.

Projekt może składać się z jednej lub wielu usług. W przypadku rozbudowanych projektów, z wieloma niezależnymi przepływami pracy, często tworzy się oddzielne usługi dla każdego z tych przepływów. Wielu programistów preferuje rozbijanie dużych projektów na mniejsze, autonomiczne usługi, z których każda realizuje jedną lub więcej funkcji. Każda usługa może być dedykowana rozwiązaniu konkretnego problemu biznesowego. Wraz z rozwojem frameworków bezserwerowych, funkcje coraz częściej udostępniane są jako usługi.

Po zdefiniowaniu funkcji jako usług, kolejnym etapem jest ich struktura i zarządzanie wersjami. Można zdecydować się na umieszczenie wszystkich usług w jednym repozytorium (mono-repo), albo na stworzenie odrębnego repozytorium dla każdej usługi (multi-repo)!

Czym jest Mono-repo?

W podejściu mono-repo wszystkie usługi projektu są przechowywane w jednym, wspólnym repozytorium. Mimo to, każda usługa może być wdrażana i zarządzana niezależnie. Usługi mogą również współdzielić biblioteki oraz fragmenty kodu.

Firmy takie jak Facebook, Google i Dropbox stosują strategię mono-repo.

Zalety Mono-repo

Podejście mono-repo posiada szereg zalet:

• Centralne miejsce przechowywania kodu, łatwo dostępne dla wszystkich członków zespołu
• Ułatwione ponowne wykorzystanie i udostępnianie kodu, sprzyjające efektywnej współpracy
• Łatwość analizy wpływu wprowadzonych zmian na cały projekt
• Optymalne rozwiązanie dla refaktoryzacji i poważniejszych zmian w kodzie
• Możliwość uzyskania ogólnego wglądu w strukturę całego projektu przez wszystkich członków zespołu
• Uproszczone zarządzanie zależnościami pomiędzy poszczególnymi modułami

Wady Mono-repo

Oczywiście, mono-repo ma także swoje wady. Jedną z kluczowych jest kwestia wydajności. Wraz ze wzrostem projektu i regularnym dodawaniem nowych plików, operacje takie jak pobieranie, aktualizowanie kodu, czy wyszukiwanie plików mogą stać się wolniejsze.

Dodatkowo, w przypadku zatrudniania zewnętrznych kontraktorów, udostępnienie całej bazy kodu może stanowić problem z perspektywy bezpieczeństwa.

Problematyczne może być również wdrożenie ciągłej integracji i ciągłego wdrażania (CI/CD), ze względu na możliwość równoczesnego wprowadzania zmian przez wielu programistów i częstą konieczność przebudowy systemu.

Duże firmy korzystające z mono-repo często posiadają specjalnie opracowane narzędzia, które pomagają im radzić sobie z problemami skalowania. Na przykład, Facebook korzysta z niestandardowego systemu plików i systemu kontroli źródła.

Czym jest multi-repo?

W podejściu multi-repo mamy do czynienia z wieloma repozytoriami, z których każde odpowiada za konkretną usługę lub bibliotekę projektu. W przypadku modyfikacji danej usługi, konieczna jest jedynie jej ponowna kompilacja, a nie całego projektu. Poszczególne osoby lub zespoły mogą pracować nad swoimi usługami, mając dostęp tylko do tych, które są im potrzebne.

Firmy takie jak Netflix i Amazon stosują architekturę multi-repo.

Zalety Multi-repo

Strategia multi-repo jest wybierana przez większą liczbę firm niż mono-repo, ze względu na następujące korzyści:

• Każda usługa i biblioteka ma swój własny system wersjonowania
• Proces pobierania i aktualizacji kodu jest szybki i dotyczy tylko konkretnych repozytoriów, co pozwala uniknąć problemów z wydajnością, nawet przy dużych projektach
• Zespoły mogą pracować niezależnie, bez konieczności dostępu do całej bazy kodu
• Szybszy rozwój i większa elastyczność
• Każda usługa może być wdrażana osobno i posiadać własny cykl wdrażania, co upraszcza implementację CI/CD
• Lepsza kontrola dostępu – poszczególne zespoły nie muszą mieć pełnego dostępu do wszystkich bibliotek, a jedynie do tych, które są im potrzebne.

Wady Multi-repo

• Zależności i biblioteki używane w różnych usługach muszą być regularnie synchronizowane, aby uniknąć problemów związanych ze starszymi wersjami
• Możliwość powstania zamkniętej kultury pracy, prowadzącej do duplikowania kodu i prób rozwiązywania tych samych problemów przez różne zespoły
• Zastosowanie różnych zestawów najlepszych praktyk przez poszczególne zespoły, utrudniające stosowanie spójnych zasad na poziomie całego projektu

Różnice między Mono i Multi Repo

Podsumujmy kluczowe różnice pomiędzy podejściem mono-repo i multi-repo:

Monorepo
Wiele repozytoriów
Cały kod projektu przechowywany jest w jednym, centralnym repozytorium
Każda usługa i projekt mają własne, odrębne repozytorium
Zespoły mogą współpracować i śledzić wzajemne zmiany
Zespoły mogą pracować autonomicznie, a zmiany w jednym repo nie wpływają na inne
Wszyscy członkowie zespołu mają dostęp do całej struktury projektu
Dostęp do konkretnego repozytorium lub usługi można ograniczyć do osób, które tego potrzebują
Problemy ze skalowaniem mogą pojawić się, gdy projekt nadmiernie się rozrasta
Dobra wydajność, ze względu na mniejszy zakres kodu w każdym repozytorium
Trudniejsza implementacja ciągłego wdrażania (CD) i ciągłej integracji (CI)
Uproszczone wdrażanie CD i CI, ponieważ każda usługa jest budowana oddzielnie
Łatwe udostępnianie bibliotek, API i wspólnych fragmentów kodu w centralnym repozytorium
Wszelkie zmiany we wspólnych bibliotekach muszą być regularnie synchronizowane we wszystkich repozytoriach

Wnioski

Zarówno mono-repo, jak i multi-repo są popularnymi strategiami, a wybór optymalnego rozwiązania zależy od wielkości projektu, jego specyficznych wymagań oraz wymaganego poziomu kontroli dostępu i wersjonowania.

Mono-repo kładzie nacisk na spójność, podczas gdy multi-repo koncentruje się na rozłączeniu. W mono-repo, zmiany dokonane przez jedną osobę są widoczne dla całego zespołu, natomiast w multi-repo, każdy zespół ma dostęp jedynie do repozytoriów z usługami, nad którymi pracuje. Jeśli chcesz połączyć zalety obu podejść, warto rozważyć użycie metanarzędzia do zarządzania wieloma projektami i bibliotekami.

Może Cię również zainteresować dostęp do darmowych materiałów edukacyjnych z zakresu Git.