Robocikowo>ROBOCIKOWO
Infrastruktura

Monorepo

AktywnyOpublikowany
Strategia przechowywania wielu projektów lub pakietów w jednym repozytorium kontroli wersji, z jawnie zdefiniowanymi relacjami między nimi.
Kluczowa innowacja
Zastąpienie wielu osobnych repozytoriów jednym repozytorium dla wielu projektów z jawnym grafem zależności, co umożliwia atomowe zmiany międzyprojektowe i współdzielenie kodu bez publikowania pakietów.
Kategoria
Infrastruktura
Poziom abstrakcji
Wzorzec
Poziom operacji
SystemWdrożenie
Zastosowania
Rozwój dużych baz kodu w organizacjachWspółdzielenie bibliotek między wieloma aplikacjamiAtomowe zmiany obejmujące wiele pakietów narazUjednolicony pipeline CI/CD dla wielu projektówMonorepo w projektach AI/ML: wspólne biblioteki, pipeline’y danych i kod modeli

Jak działa

Wszystkie projekty żyją w jednym drzewie katalogów jednego repozytorium. Dedykowane narzędzia (np. Nx, Turborepo, Bazel) analizują zależności między projektami i budują graf zadań, dzięki czemu operacje budowania, testowania i lintowania wykonują się tylko dla projektów dotkniętych daną zmianą oraz dla ich zależnych. Wyniki zadań są cache’owane (lokalnie i zdalnie), co pozwala pomijać ponowne wykonywanie niezmienionej pracy. Pojedyncza zmiana może atomowo zmodyfikować kilka projektów naraz w jednym commicie, a wspólny pipeline CI weryfikuje całość. Organizacje o bardzo dużych bazach kodu stosują dodatkowo wyspecjalizowane systemy kontroli wersji skalujące się do miliardów linii (Piper w Google, Sapling w Meta).

Rozwiązany problem

W modelu wielu osobnych repozytoriów (polyrepo) współdzielenie kodu wymaga publikowania i wersjonowania pakietów, a zmiana obejmująca kilka projektów rozpada się na wiele ręcznie koordynowanych commitów i pull requestów. Prowadzi to do utraty kontekstu, duplikacji konfiguracji i rozjazdu wersji zależności. Monorepo rozwiązuje te problemy, umożliwiając atomowe zmiany międzyprojektowe, jedno źródło prawdy dla zależności i współdzielenie kodu bez narzutu publikacji pakietów.

Komponenty

Pojedyncze repozytorium kontroli wersjiWspólny magazyn kodu dla wszystkich projektów

Jedno repozytorium (np. Git) przechowujące cały kod organizacji lub produktu w jednym drzewie katalogów.

Granice projektów/pakietówPodział na odrębne, enkapsulowane jednostki

Jawnie wydzielone projekty (aplikacje, biblioteki, narzędzia) z enkapsulacją, odróżniające monorepo od zwykłej kolokacji kodu.

Graf zależnościJawne relacje między projektami

Model zależności między projektami, na podstawie którego narzędzia określają, co zbudować i przetestować po zmianie.

System budowania z cacheInkrementalne budowanie i uruchamianie zadań

Narzędzia (Nx, Turborepo, Bazel) wykonujące zadania tylko dla zmienionych projektów i cache’ujące wyniki lokalnie oraz zdalnie.

Ewolucja

2016
Google opisuje swoje monorepo w Communications of the ACM
Punkt przełomowy

Artykuł Rachel Potvin i Josha Levenberga „Why Google Stores Billions of Lines of Code in a Single Repository” spopularyzował monorepo w dużej skali.

Why Google Stores Billions of Lines of Code in a Single Repository (artykuł)

Hiperparametry (konfigurowalne osie)

Granularność grafu zależnościWysoka

Jak drobnoziarniście definiowane są projekty i ich wzajemne zależności.

Cache budowaniaWysoka

Strategia cache’owania wyników zadań (lokalnie i/lub zdalnie), kluczowa dla skalowalności monorepo.

Orkiestracja zadańŚrednia

Sposób zrównoleglania i kolejkowania zadań budowania/testów w oparciu o graf zależności.

Granice własności koduŚrednia

Reguły własności i uprawnień (np. CODEOWNERS) wyznaczające odpowiedzialność zespołów za części monorepo.