Kakšne so strategije monorepo vs polyrepo?

Question

Accepted Answer

**Monorepo** (ena repozitorija za več projektov/storitev) in **polyrepo** (ločena repozitorija za vsak projekt) sta dve strategiji za organizacijo kode v več projektih. Obe imata pomembne kompromise, ki vplivajo na sodelovanje, orodja in razširljivost — njihovo razumevanje je ključno za oblikovanje važnih arhitekturnih odločitev.

## Monorepo — ena repozitorija za vse

```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 — ena repozitorija 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.
```

## Izbira

```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.
```

## Zakaj je to pomembno

Razumevanje strategij monorepo vs polyrepo je dragoceno znanje za vodilne ravni za **sprejemanje premišljenih arhitekturnih odločitev o organizaciji kode**, kar je важna odločitev s širokim dosegom, zato je uporabno za senior/arhitekturne vloge.

Obe strategiji — **monorepo** (mnogo projektov v eni repozitoriji) in **polyrepo** (ločena repozitorija za vsak projekt) — predstavljata temeljno različni organizacijski filozofiji z resničnimi kompromisi. **Prednosti monorepoja** (enostavna skupna koda in refaktoriranje, **atomske medprojektne spremembe** — spreminjanje API-ja in vseh njegovih porabnikov skupaj, enotna orodja in standardi, poenostavljeno upravljanje odvisnosti) ga delajo zmogljiv za tesno povezane projekte s težavo deljenjem kode, vendar zahteva pomembne naložbe v **razširljiva orodja** (Nx, Turborepo, Bazel, redke checkouty, pametne CI) za učinkovito obravnavanje velike repozitorije. **Prednosti polyrepoja** (jasna lastništva in meje, neodvisno oblikovanje verzij in izdajnih ciklov, manjši osredotočeni repoji, natančen dostop) ustrezajo neodvisnim projektom in timom, vendar **delijo kodo težje** (izdajanje/poraba paketov, usklajevanje verzij) in **medprojektne spremembe bolj boleče** (usklajevanje zahtevkov za spremembe v več repozitorijih).

Razumevanje teh kompromisov in kako **izbrati** (monorepo za tesno povezane projekte s skupno kodo, pripravljene vložiti v orodja; polyrepo za neodvisne projekte in time s jasnimi mejami) odraža arhitekturni presoj, ki se pričakuje na vodilnih ravneh — prepoznavanje, da ni univerzalnega odgovora in da je pravi izbor odvisen od povezave, obsega, strukture timov in naložb v orodja.

Ker je organizacija kode v več projektih pomembna arhitekturna odločitev, ki vpliva na sodelovanje, orodja, razširljivost in avtonomijo timov, in ker razumevanje kompromisov monorepo/polyrepo oblikuje to posledično odločitev, je razumevanje strategij monorepo vs polyrepo dragoceno znanje za vodilne ravni za arhitekturno odločanje, pogosto razpravljana tema, kjer razumevanje kompromisov (namesto dogmatskega favoriziranja enega) odraža zorelo presojo, ki se pričakuje na vodilnih ravneh pri oblikovanju načina organizacije kode v organizaciji.