Was sind Monorepo- vs. Polyrepo-Strategien?

Question

Accepted Answer

**Monorepo** (ein Repository für viele Projekte/Services) und **Polyrepo** (ein separates Repository pro Projekt) sind zwei Strategien zur Organisation von Code über mehrere Projekte hinweg. Jede hat erhebliche Trade-offs, die Zusammenarbeit, Tooling und Skalierung beeinflussen – ihr Verständnis informiert wichtige architektonische Entscheidungen.

## Monorepo — ein Repository für alles

```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 — ein Repository pro 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.
```

## Auswahl

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

## Warum es wichtig ist

Das Verständnis von Monorepo- vs. Polyrepo-Strategien ist wertvolles Wissen auf Senior-Level für **fundierte architektonische Entscheidungen über Code-Organisation** – eine bedeutende Wahl mit weitreichenden Auswirkungen, daher nützlich für Senior- und architektonische Rollen.

Die beiden Ansätze – **Monorepo** (viele Projekte in einem Repository) und **Polyrepo** (ein separates Repository pro Projekt) – repräsentieren grundlegend unterschiedliche Organisationsphilosophien mit echten Trade-offs. **Monorepo**-Vorteile (einfach gemeinsamer Code und Refactoring, **atomare projektübergreifende Commits** – API-Änderungen und alle ihre Consumer zusammen ändern, einheitliches Tooling und Standards, vereinfachtes Dependency-Management) machen es kraftvoll für eng gekoppelte Projekte mit hohem Code-Sharing, erfordern aber erhebliche Investitionen in **Skalierungs-Tooling** (Nx, Turborepo, Bazel, sparse checkout, intelligente CI), um das große Repository effizient zu handhaben. **Polyrepo**-Vorteile (klare Ownership und Grenzen, unabhängige Versionierung und Release-Zyklen, kleinere fokussierte Repos, granulare Zugriffskontrolle) eignen sich für unabhängige Projekte und Teams, machen aber **gemeinsamen Code schwieriger** (Publishing/Consuming von Paketen, Versions-Koordination) und **projektübergreifende Änderungen schmerzhaft** (Koordination von PRs über viele Repos hinweg).

Das Verständnis dieser Trade-offs und wie man **wählt** (Monorepo für eng gekoppelte, Code-Sharing-Projekte, die in Tooling investieren wollen; Polyrepo für unabhängige Projekte und Teams mit klaren Grenzen) spiegelt das auf Senior-Level erwartete architektonische Urteilsvermögen wider – erkennend, dass es keine universelle Antwort gibt und die richtige Wahl von Kopplung, Skalierung, Team-Struktur und Tooling-Investition abhängt.

Da Code-Organisation über mehrere Projekte eine bedeutende architektonische Entscheidung ist, die Zusammenarbeit, Tooling, Skalierung und Team-Autonomie beeinflusst, und da das Verständnis der Monorepo/Polyrepo-Trade-offs diese folgenreiche Entscheidung informiert, ist das Verständnis von Monorepo- vs. Polyrepo-Strategien wertvolles Wissen auf Senior-Level für architektonische Entscheidungsfindung – ein häufig diskutiertes Thema, bei dem das Verständnis der Trade-offs (statt dogmatisches Favorisieren eines Ansatzes) das reife Urteilsvermögen widerspiegelt, das von Senior-Rollen erwartet wird, die mitgestalten, wie eine Organisation ihren Code strukturiert.