Mitä ovat monorepo vs polyrepo -strategiat?

Question

Accepted Answer

**Monorepo** (yksi tietovarasto monille projekteille/palveluille) ja **polyrepo** (erillinen tietovarasto per projekti) ovat kaksi strategiaa koodin organisoimiseen useiden projektien välillä. Kummallakin on merkittäviä kompromisseja, jotka vaikuttavat yhteistyöhön, työkaluihin ja skaalautuvuuteen — niiden ymmärtäminen ohjaa tärkeitä arkkitehtuuripäätöksiä.

## Monorepo — yksi varasto kaikille

```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 — varasto per projekti

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

## Valinta

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

## Miksi sillä on merkitystä

Monorepo vs polyrepo -strategioiden ymmärtäminen on arvokas senioriyritystason tieto **rationaalisten arkkitehtuuripäätösten tekemiseen koodin organisoinnista**, mikä on merkittävä valinta, jolla on laajat vaikutukset, joten se on hyödyllinen senioritehtäviin ja arkkitehtuurirooleihin.

Kaksi lähestymistapaa — **monorepo** (monia projekteja yhdessä tietovarastossa) ja **polyrepo** (erillinen tietovarasto per projekti) — edustavat perustavanlaatuisesti erilaisia organisaatiofilosofioita todellisilla kompromisseilla. **Monorepon** edut (helppo jaettu koodi ja refaktorointi, **atomiset projektienvälisten committien** — API:n muuttaminen ja kaikki sen käyttäjät kerralla, yhtenäinen työkalut ja standardit, yksinkertaistettu riippuvuuksien hallinta) tekevät siitä tehokkaan tiiviisti kytketyille projekteille, joissa on paljon koodin jakamista, mutta se vaatii merkittävää investointia **skaalautuviin työkaluihin** (Nx, Turborepo, Bazel, sparse checkout, älykäs CI) suurten tietovarastojen tehokkaaseen käsittelyyn. **Polyrepon** edut (selkeä omistajuus ja rajat, itsenäiset versiointi ja julkaisusyklit, pienemmät fokusoidut varasto, piilevä pääsy) sopivat riippumattomille projekteille ja tiimeille, mutta tekevät **jaetusta koodista hankalampaa** (pakettien julkaisu/kulutus, version koordinointi) ja **koko järjestelmän muutoksista kivuliasta** (PR:ien koordinointi monessa varastossa).

Näiden kompromissien ymmärtäminen ja kuinka **valita** (monorepo tiiviisti kytkeytyneille, koodia jaaville projekteille, jotka ovat valmiita investoimaan työkaluihin; polyrepo riippumattomille projekteille ja tiimeille, joilla on selkeät rajat) heijastaa senioriyritystasolla odotettavaa arkkitehtuurin harkintaa — tunnistaminen siitä, että ei ole universaalia vastausta ja oikea valinta riippuu kytkennästä, skaalasta, tiimin rakenteesta ja työkalun investoinnista.

Koska koodin organisointi useiden projektien välillä on merkittävä arkkitehtuuripäätös, joka vaikuttaa yhteistyöhön, työkaluihin, skaalaukseen ja tiimin autonomiaan, ja koska monorepo/polyrepo-kompromissien ymmärtäminen ohjaa tätä merkittävää valintaa, monorepo vs polyrepo -strategioiden ymmärtäminen on arvokas senioriyritystason tieto arkkitehtuurin päätöksentekoon, usein keskusteltu aihe, jossa kompromissien ymmärtäminen (sen sijaan, että sokosti suositaan yhtä) heijastaa kypsää harkintaa, jota odotetaan seniorrooleissa, jotka muodostavat sitä, miten organisaatio rakentaa koodinsa.