Hvad er monorepo vs polyrepo strategier?

Question

Accepted Answer

**Monorepo** (ét repository til mange projekter/services) og **polyrepo** (et separat repository per projekt) er to strategier til at organisere kode på tværs af flere projekter. Hver tilgang har betydelige fordele og ulemper, der påvirker samarbejde, værktøjer og skalering — at forstå dem informerer vigtige arkitektoniske beslutninger.

## Monorepo — ét repository til alt

```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 — et repository per 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.
```

## Valg

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

## Hvorfor det betyder noget

At forstå monorepo vs polyrepo strategier er værdifuld viden på seniorniveau for **at træffe velovervejet arkitektoniske beslutninger om kodeorganisering**, et betydningsfuldt valg med brede konsekvenser, så det er nyttigt for senior-/arkitektur-roller.

De to tilgange — **monorepo** (mange projekter i ét repository) og **polyrepo** (et separat repository per projekt) — repræsenterer fundamentalt forskellige organisatoriske filosofier med virkelige fordele og ulemper. **Monorepo** fordelene (nem delt kode og refaktorering, **atomare cross-projekt commits** — ændring af et API og alle dets forbrugere samtidigt, ensartede værktøjer og standarder, forenklet dependency management) gør det kraftfuldt for tæt koblede projekter med omfattende kodedeling, men det kræver betydelig investering i **skaleringsværktøjer** (Nx, Turborepo, Bazel, sparse checkout, smart CI) til effektivt at håndtere det store repository. **Polyrepo** fordelene (klar ejerskab og grænser, uafhængige versionerings- og release-cyklusser, mindre fokuserede repositories, granulær adgangskontrol) passer til uafhængige projekter og teams, men gør **delt kode sværere** (publicering/forbrug af packages, versionskoordinering) og **krydsgennemskærende ændringer smertefulde** (koordinering af PRs på tværs af mange repositories).

At forstå disse fordele og ulemper og hvordan man **vælger** (monorepo for tæt koblet projekter med kodedeling, villige til at investere i værktøjer; polyrepo for uafhængige projekter og teams med klare grænser) afspejler den arkitektoniske dømmekraft, der forventes på seniorniveauer — at genkende, at der ikke er et universelt svar, og det rigtige valg afhænger af koblingsgrad, skala, teamstruktur og værktøjsinvestering.

Da kodeorganisering på tværs af flere projekter er en betydningsfuld arkitektonisk beslutning, der påvirker samarbejde, værktøjer, skalering og team-autonomi, og da forståelse af monorepo/polyrepo fordelene og ulemperne informerer denne vigtige beslutning, er forståelse af monorepo vs polyrepo strategier værdifuld viden på seniorniveau for arkitektonisk beslutningstagning, et hyppigt debatteret emne, hvor forståelse af fordelene og ulemperne (i stedet for dogmatisk at favorisere én) afspejler den modne dømmekraft, der forventes for seniorrollen med at forme, hvordan en organisation strukturerer sin kode.