Mik a monorepo versus polyrepo stratégiák?

Question

Accepted Answer

**Monorepo** (egy repository sok projekt/szolgáltatáshoz) és **polyrepo** (projektenkénti külön repository) két stratégia a kód szervezésére több projekt között. Mindkettőnek jelentős kompromisszumai vannak, amelyek hatnak az együttműködésre, az eszközözethasználatra és a méretezésre — ezek megértése fontos architekturális döntésekhez vezet.

## Monorepo — egy repository mindegyikhez

```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 — egy repo projektenkénti

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

## Választás

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

## Miért számít

A monorepo versus polyrepo stratégiák megértése értékes senior szintű tudás **a kód szervezésével kapcsolatos helyes architekturális döntésekhez**, amely egy jelentős választás széles körű hatásokkal, így hasznos senior/architekturális szerepekben.

A két megközelítés — **monorepo** (sok projekt egy repository-ban) és **polyrepo** (külön repository projektenkénti) — alapvetően eltérő szervezeti filozófiákat képviselnek valós kompromisszumokkal. **Monorepo** előnyei (könnyű megosztott kód és refactoring, **atomi keresztprojekt commitok** — API megváltoztatása és összes fogyasztójának közös frissítése, unified tooling és standardok, egyszerűsített függőségkezelés) erőssé teszik szorosan kapcsolódó projektekhez nagy kódmegosztással, de jelentős befektetést igényelnek **skálázó toolingba** (Nx, Turborepo, Bazel, sparse checkout, okos CI) a nagy repository hatékony kezeléséhez. **Polyrepo** előnyei (egyértelmű felelősség és határok, független verziókezelés és kiadási ciklus, kisebb fókuszált repok, granularis hozzáférés) független projektekhez és csapatokhoz illeszkednek, de **megosztott kódot nehezítik** (csomagok publikálása/fogyasztása, verzió koordináció) és **keresztmetszeti változtatások fájdalmasak** (PR koordináció sok repo között).

A kompromisszumok megértése és az **választás** (monorepo szorosan kapcsolódó, kódmegosztó projektekhez, akik tooling befektetésre hajlandóak; polyrepo független projektekhez és csapatokhoz egyértelmű határokkal) senior szintű architekturális ítéletet tükröz — felismerve, hogy nincs egyetemes válasz és a helyes választás a kötésektől, skálától, csapatszerkezettől és tooling befektetésektől függ.

Mivel a kód szervezése több projekt között egy jelentős architekturális döntés, amely hatást gyakorol az együttműködésre, tooling-ra, skálázásra és csapat autonómiára, és mivel a monorepo/polyrepo kompromisszumok megértése ezt a súlyos döntést informálja, a monorepo versus polyrepo stratégiák megértése értékes senior szintű tudás architekturális döntéshozatalhoz, egy gyakran vitatott téma ahol a kompromisszumok megértése (ahelyett, hogy dogmatikusan az egyiket favorizálnánk) tükrözi az érett ítéletet, amely senior szerepekben várható a kód szervezésének alakításában egy szervezetben.