Hva er monorepo versus polyrepo-strategier?

Question

Accepted Answer

**Monorepo** (ett repository for mange prosjekter/tjenester) og **polyrepo** (ett eget repository per prosjekt) er to strategier for å organisere kode på tvers av flere prosjekter. Hver tilnærming har betydelige avveininger som påvirker samarbeid, verktøy og skalering — å forstå dem informerer viktige arkitektoniske beslutninger.

## Monorepo — ett repository for 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 — ett repository per prosjekt

```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 betyr noe

Å forstå monorepo versus polyrepo-strategier er verdifull kunnskap på seniorøt for **å ta velgrunnede arkitektoniske beslutninger om kodeorganisering**, et betydelig valg med brede implikasjoner, så det er nyttig for senior- og arkitektoniske roller.

De to tilnærmingene — **monorepo** (mange prosjekter i ett repository) og **polyrepo** (ett eget repository per prosjekt) — representerer fundamentalt ulike organisasjonsfilosofier med reelle avveininger. **Monorepo**-fordelene (lett delt kode og refaktorering, **atomare tvers-prosjekt-commits** — endre et API og alle dets forbrukere sammen, enhetlige verktøy og standarder, forenklet avhengighetshåndtering) gjør den kraftfull for tett koblede prosjekter med betydelig kodedeling, men det krever betydelig investering i **skalerbar verktøy** (Nx, Turborepo, Bazel, sparse checkout, smart CI) for å håndtere det store repositoryet effektivt. **Polyrepo**-fordelene (klar eierskap og grenser, uavhengig versjonering og utgivelsessykluser, mindre fokuserte repositories, granulær tilgangskontroll) passer uavhengige prosjekter og team, men gjør **delt kode vanskeligere** (publisering/forbruk av pakker, versjonkoordinering) og **tverrsnittende endringer smertefulle** (koordinering av PR-er på tvers av mange repositories).

Å forstå disse avveiningene og hvordan man **velger** (monorepo for tett koblede, kodedelende prosjekter som er villige til å investere i verktøy; polyrepo for uavhengige prosjekter og team med klare grenser) gjenspeiler den arkitektoniske dømmekraften som forventes på seniorøt — å erkjenne at det ikke finnes et universelt svar og det riktige valget avhenger av kobling, skala, teamstruktur og verktøyinvestering.

Siden kodeorganisering på tvers av flere prosjekter er en betydelig arkitektonisk beslutning som påvirker samarbeid, verktøy, skalering og teamautonomi, og siden forståelse av monorepo/polyrepo-avveiningene informerer denne konsekvensfylte valget, er forståelse av monorepo versus polyrepo-strategier verdifull seniorøt-kunnskap for arkitektonisk beslutningstaking, et hyppig debattert tema der forståelse av avveiningene (i stedet for dogmatisk å favorisere den ene) gjenspeiler den modne dømmekraften som forventes for seniorroller som former hvordan en organisasjon strukturerer koden sin.