Monorepo – Our Experience

Original Article ↗ Hacker News Discussion ↗

CI/CD and Selective Builds

  • Many argue CI/CD isn’t inherently harder with monorepos; modern systems (GitHub Actions, GitLab, Azure DevOps, AWS CodeBuild/CodePipeline) support path-based triggers and per-directory workflows.
  • Others report real friction, especially when migrating from many repos to one: redoing pipelines, parallelization, and “only run what’s affected” logic can be non‑trivial.
  • Selective builds/tests are seen as essential for large monorepos, but commenters warn of hidden dependencies (config, schemas, scripts) that tools can miss, so periodic full runs are still needed.
  • Some CI systems give “green” status if only a subset of tests run, which may mean “no new breakage” rather than “everything passes”; teams differ on whether this is desirable.

Versioning, Contracts, and API Design

  • One camp views monorepos as a workaround for poor versioning and broken contracts; they argue that proper semantic versioning and backward‑compatible APIs make repo layout largely irrelevant.
  • Counter‑arguments: versioning and contract preservation are expensive in practice, especially when you own both producer and consumer. Monorepos enable lockstep refactors and eliminate “version hell” and stale dependencies.
  • There’s a deep sub‑thread about whether enforcing strict API stability everywhere is realistic or just pushes huge long‑term costs and rigidity.

Deployment Strategy and Release Management

  • Several argue repo structure should mirror deployment: 1 repo per independently deployed artifact; otherwise monorepos with many independent services complicate understanding “what’s in prod.”
  • Others report success with monorepos containing hundreds of apps/services, using explicit release specs, GitOps, blue/green, or per‑directory deploy pipelines.
  • Debate over coordinated deploys: monorepos make cross‑service breaking changes easier to land atomically, but don’t remove mixed‑version fleets during rollouts.

Tooling, Scale, and Performance

  • Large monorepos typically require strong tooling: Bazel/Buck/Please for “build what changed,” Meta’s Sapling/EdenFS, Microsoft Scalar, fsmonitor, etc.
  • Some report git performance collapsing at ~10M+ files; others note big-company internal systems (Google’s, Meta’s) are not easily replicated in open source.

Organizational and Social Factors

  • Repo boundaries often mirror org boundaries (Conway’s Law). Multi‑repo can enforce clear ownership and team interfaces; monorepo can blur ownership and create “core/DMZ” directories nobody wants to touch.
  • Others counter that with codeowners, visibility controls, and strong library governance, monorepos can maintain ownership just as well.

Overall Sentiment

  • Strong consensus that monorepo vs multi‑repo is a tradeoff, not a silver bullet.
  • Monorepos shine for tightly coupled systems, frequent cross‑cutting changes, and small to medium teams with good tooling.
  • Multi‑repo shines for independent products, strong API boundaries, and access control.
  • Several warn against blindly copying big-tech patterns without matching their scale, tooling, and engineering discipline.