Die ewige Debatte

Ein Monorepo halt viele Projekte in einem Repository; Multi-Repo teilt sie auf.

Was Monorepo bietet

• Atomare projektubergreifende Commits.
• Einzelne Quelle der Wahrheit.
• Leichteres grossangelegtes Refactoring.
• Einheitliches Tooling.

Was Monorepo kostet

• Repo-Grosse wachst unbegrenzt.
• Tooling-Investment.
• Berechtigungs-Granularitat schwieriger.
• CI muss affected-only Builds machen.

Was Multi-Repo bietet

• Unabhangige Release-Kadenz.
• Kleinere, fokussierte Repos.
• Naturliche Berechtigungsgrenzen.
• Fehler-Isolation.

Was Multi-Repo kostet

• Repo-ubergreifende Anderungen erfordern koordinierte PRs.
• Geteilte Bibliotheken werden zu Versionsproblemen.
• Tooling driftet.
• Auffindbarkeit leidet.

Monorepo-Tooling-Essentials

git sparse-checkout set apps/web shared/ui
git clone --filter=blob:none <url>
npx nx affected:test --base=main

Multi-Repo-Koordinationstools

gh repo list myorg --limit 200
for repo in $(gh repo list myorg --json name -q '.[].name'); do
  gh pr list -R myorg/$repo
done

Hybride Ansatze

• Monorepo fur App-Code, separate Repos fur Infrastruktur.
• Monorepo pro Business-Domain.
• Multi-Repo mit einem Meta-Repo aus Submodulen.

Ehrliche Entscheidungsfaktoren

• Unter 20 Ingenieure: Multi-Repo ist gut.
• Uber 200 Ingenieure: Monorepo gewinnt.