Quali sono le strategie monorepo e polyrepo?

Question

Accepted Answer

**Monorepo** (un repository per molti progetti/servizi) e **polyrepo** (un repository separato per progetto) sono due strategie per organizzare il codice su più progetti. Ognuna ha trade-off significativi che influenzano la collaborazione, gli strumenti e la scalabilità — comprenderle informa decisioni architetturali importanti.

## Monorepo — un repository per tutto

```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 — un repository per progetto

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

## Scelta

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

## Perché è importante

Comprendere le strategie monorepo e polyrepo è una conoscenza preziosa a livello senior per **prendere decisioni architetturali consapevoli sull'organizzazione del codice**, una scelta significativa con implicazioni ampie, quindi utile per ruoli senior/architetturali.

I due approcci — **monorepo** (molti progetti in un repository) e **polyrepo** (un repository separato per progetto) — rappresentano filosofie organizzative fondamentalmente diverse con veri trade-off. I vantaggi del **monorepo** (codice condiviso facile e refactoring, **commit atomici tra progetti** — modificare un'API e tutti i suoi consumatori insieme, tooling unificato e standard, gestione dipendenze semplificata) lo rendono potente per progetti strettamente accoppiati con forte code sharing, ma richiede investimento significativo in **tooling di scalabilità** (Nx, Turborepo, Bazel, sparse checkout, CI intelligente) per gestire il repository grande in modo efficiente. I vantaggi del **polyrepo** (proprietà chiara e confini, versioning e cicli di rilascio indipendenti, repository piccoli e focalizzati, accesso granulare) si adattano a progetti e team indipendenti, ma rendono il **codice condiviso più difficile** (pubblicazione/consumo di pacchetti, coordinamento versioni) e i **cambiamenti trasversali dolorosi** (coordinamento PR su molti repository).

Comprendere questi trade-off e come **scegliere** (monorepo per progetti strettamente accoppiati con code sharing che investono in tooling; polyrepo per progetti indipendenti e team con confini chiari) riflette il giudizio architetturale atteso a livello senior — riconoscendo che non esiste una risposta universale e la scelta giusta dipende dall'accoppiamento, scala, struttura del team e investimento in tooling.

Poiché l'organizzazione del codice su più progetti è una decisione architetturale significativa che influenza collaborazione, tooling, scalabilità e autonomia del team, e poiché comprendere i trade-off monorepo/polyrepo informa questa scelta consequenziale, capire le strategie monorepo e polyrepo è una conoscenza preziosa a livello senior per il decision-making architetturale, un argomento frequentemente dibattuto dove comprendere i trade-off (piuttosto che favorire dogmaticamente uno) riflette il giudizio maturo atteso per ruoli senior che modellano come un'organizzazione struttura il suo codice.