Jakie są strategie monorepo vs polyrepo?

Question

Accepted Answer

**Monorepo** (jedno repozytorium dla wielu projektów/serwisów) i **polyrepo** (osobne repozytorium dla każdego projektu) to dwie strategie organizacji kodu w wielu projektach. Każda ma znaczące kompromisy wpływające na współpracę, narzędzia i skalowanie — zrozumienie ich informuje o ważnych decyzjach architektonicznych.

## Monorepo — jedno repozytorium na wszystko

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — jedno repozytorium na projekt

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Wybór

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Dlaczego to ważne

Zrozumienie strategii monorepo vs polyrepo jest cenną wiedzą na poziomie senior do **podejmowania świadomych decyzji architektonicznych dotyczących organizacji kodu**, istotnego wyboru o szerokich implikacjach, przydatnym dla ról senior/architektonicznych.

Dwa podejścia — **monorepo** (wiele projektów w jednym repozytorium) i **polyrepo** (osobne repozytorium dla każdego projektu) — reprezentują fundamentalnie różne filozofie organizacyjne z rzeczywistymi kompromisami. Zalety **monorepo** (łatwy dostęp do wspólnego kodu i refactoring, **atomowe commity cross-projektowe** — zmiana API i wszystkich jego konsumentów jednocześnie, ujednolicone narzędzia i standardy, uproszczone zarządzanie zależnościami) czynią go potężnym dla projektów ściśle powiązanych z intensywnym dzieleniem kodu, ale wymaga to znaczącej inwestycji w **narzędzia do skalowania** (Nx, Turborepo, Bazel, sparse checkout, inteligentny CI) do efektywnego obsługiwania dużego repozytorium. Zalety **polyrepo** (jasna własność i granice, niezależne wersjonowanie i cykle wydań, mniejsze, skoncentrowane repozytoria, granularna kontrola dostępu) odpowiadają niezależnym projektom i zespołom, ale sprawiają, że **wspólny kod jest trudniejszy** (publikowanie/konsumowanie pakietów, koordynacja wersji) i **zmiany cross-cutting są bolesne** (koordynacja pull requestów w wielu repozytoriach).

Zrozumienie tych kompromisów i sposobu **wyboru** (monorepo dla ściśle powiązanych projektów z dzieleniem kodu gotowych do inwestycji w narzędzia; polyrepo dla niezależnych projektów i zespołów z jasyno zdefiniowanymi granicami) odzwierciedla osąd architektoniczny oczekiwany na poziomie senior — uznanie, że nie ma uniwersalnej odpowiedzi i właściwy wybór zależy od sprzężenia, skali, struktury zespołu i inwestycji w narzędzia.

Ponieważ organizacja kodu w wielu projektach to istotna decyzja architektoniczna wpływająca na współpracę, narzędzia, skalowanie i autonomię zespołu, a zrozumienie kompromisów monorepo/polyrepo informuje tę konsekwentną decyzję, zrozumienie strategii monorepo vs polyrepo jest cenną wiedzą na poziomie senior do decyzji architektonicznych, często debatowanym tematem, gdzie zrozumienie kompromisów (zamiast dogmatycznego faworyzowania jednego) odzwierciedla dojrzały osąd oczekiwany dla ról senior kształtujących sposób, w jaki organizacja strukturyzuje swój kod.