Какие существуют стратегии monorepo и polyrepo?

Question

Accepted Answer

**Monorepo** (один репозиторий для множества проектов/сервисов) и **polyrepo** (отдельный репозиторий для каждого проекта) — два подхода к организации кода для нескольких проектов. Каждый из них имеет значительные компромиссы, влияющие на сотрудничество, инструменты и масштабируемость — понимание их помогает принимать важные архитектурные решения.

## Monorepo — один репозиторий для всего

```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 — репозиторий на проект

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

## Выбор

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

## Почему это важно

Понимание стратегий monorepo и polyrepo — это ценное знание для senior-уровня для **принятия обоснованных архитектурных решений об организации кода**, значительный выбор с широкими последствиями, поэтому он полезен для senior/архитектурных ролей.

Два подхода — **monorepo** (множество проектов в одном репозитории) и **polyrepo** (отдельный репозиторий для каждого проекта) — представляют фундаментально разные организационные философии с реальными компромиссами. Преимущества **monorepo** (простота общего кода и рефакторинга, **атомарные кросс-проектные коммиты** — изменение API и всех его потребителей вместе, унифицированные инструменты и стандарты, упрощённое управление зависимостями) делают его мощным для тесно связанных проектов с интенсивным обменом кодом, но это требует значительных инвестиций в **масштабируемые инструменты** (Nx, Turborepo, Bazel, sparse checkout, умный CI) для эффективной работы с большим репозиторием. Преимущества **polyrepo** (чёткая собственность и границы, независимое версионирование и циклы выпусков, меньшие сфокусированные репозитории, гранулярный контроль доступа) подходят для независимых проектов и команд, но затрудняют **общий код** (публикация/потребление пакетов, координация версий) и **кросс-проектные изменения** (координация PR'ов между множеством репозиториев).

Понимание этих компромиссов и способность **выбирать** (monorepo для тесно связанных проектов с обменом кодом, готовых инвестировать в инструменты; polyrepo для независимых проектов и команд с чёткими границами) отражает архитектурное суждение, ожидаемое на senior-уровне — признание того, что универсального ответа нет и правильный выбор зависит от связанности, масштаба, структуры команды и инвестиций в инструменты.

Поскольку организация кода для нескольких проектов — это значительное архитектурное решение, влияющее на сотрудничество, инструменты, масштабируемость и автономию команды, и поскольку понимание компромиссов monorepo/polyrepo информирует это важное решение, знание стратегий monorepo и polyrepo — ценное знание senior-уровня для архитектурного принятия решений, часто обсуждаемая тема, где понимание компромиссов (а не догматичное предпочтение одного) отражает зрелое суждение, ожидаемое для senior-ролей, формирующих то, как организация структурирует свой код.