Tôi từng thấy một startup có 12 repos để quản lý một sản phẩm duy nhất. Mỗi service là một repo riêng biệt, nhìn có vẻ "microservices" và "scalable", nhưng thực tế? Mỗi lần thay đổi một thư viện chung, họ phải:
1Commit vào repo A
2Release version mới
3Update dependency ở 11 repos khác
4Chờ CI/CD của từng cái
5Reconcile breaking changes khi có
Một bug fix đơn giản thành một epic 3 tuần. Và đó chỉ là một bài học nhỏ mà nhiều team phải trải qua khi chưa suy nghĩ kỹ về chiến lược repository.
Cái gì là Monorepo, cái gì là Polyrepo?
Monorepo là một repository duy nhất chứa nhiều projects/packages. Điều này không có nghĩa là monolithic. You have Facebook, Google, Bazel, Nx ecosystem chứng minh điều này.
Polyrepo là cách truyền thống: mỗi project có một repo riêng. Git submodules, private npm packages, semantic versioning bắt buộc.
Nghe đơn giản, nhưng cái khó nằm ở chi tiết.
Monorepo: Thực Tế Không Phải Toàn Hoa Hồng
Chia sẻ bài viết
Bài viết liên quan
Bạn cần tư vấn về công nghệ?
Đội ngũ Idflow luôn sẵn sàng hỗ trợ bạn trong hành trình chuyển đổi số.
Tôi sẽ không nói monorepo là "tương lai" vì điều đó không luôn đúng.
Lợi ích thực sự:
Một team 10 người ở Monorepo có thể refactor API contract và cập nhật cùng lúc ở frontend, backend, CLI tool, mobile SDK. Không cần negotiate breaking changes qua version number, không cần waiting period. Tất cả thay đổi xảy ra trong một atomic commit.
Tooling support tốt hơn. Với Nx hay Turborepo, bạn có:
- Incremental builds (chỉ rebuild những cái thay đổi)
- Distributed caching (chia sẻ build artifacts giữa developers)
- Dependency graphs visualization (hiểu rõ architecture)
Google sử dụng Bazel để quản lý 200 triệu dòng code trong một monorepo duy nhất. Đó không phải tỷ lệ "người Việt" nhưng pattern đó applicable.
Tuy nhiên...
Monorepo phải trả giá về governance. Khi cơ sở code lớn, CI/CD lâu hơn (ngay cả với caching, một bad commit từ team A vẫn làm chậm release của team B). Phần quyền truy cập code: mỗi thứ đều visible cho mọi người, vấn đề gì về security hay IP nội bộ?
Một doanh nghiệp ở Việt Nam có 50 engineers cần quản lý monorepo phức tạp → cần một DevOps/Platform engineer chuyên dành. Chi phí ẩn là thực.
Polyrepo: Vì Sao Nó Vẫn Có Ý Nghĩa
Khi bạn có truly independent teams, polyrepo shine.
Một API team, một Mobile team, một Web team không cần biết nhau. Mỗi cái có release cycle riêng, library versions riêng. Team A release 10 lần một tuần, team B release 1 lần một tháng → cách biệt này không quan trọng nếu interface/contract stable.
Công cụ như Pnpm workspaces, npm monorepo, hoặc thậm chí semantic versioning + private Verdaccio instance giúp share code mà không cần monorepo. Một công ty SaaS mid-size ở TP HCM dùng 7 repos + 1 monorepo shared utilities = hybrid approach. Cách này cân bằng.
Tuy nhiên...
Polyrepo có version hell. Bạn release library v2.0 mới, nhưng 3 repositories khác chưa migrate. Sau 1 năm, bạn support cả v1 lẫn v2. Duplicate logic, security patches phải backport. Performance insight của DevOps kém vì không có unified tracing/monitoring.
Con số Mà Ít Ai Nói
Một số mà tôi thấy từ industry report: Polyrepo setup giúp giảm build time 30-40% so với monorepo quản lý tệ. Nhưng giảm developer productivity 50% vì overhead quản lý dependencies. Tính lại thôi, monorepo hợp lý hơn.
Một lý do ít ai nhắc: Git history complexity. Polyrepo chặt hơn về responsibility (ai thay đổi cái gì dễ trace). Monorepo phức tạp hơn vì công dụng refactoring shared code.
Thực Tế ở Đây
Quyết định monorepo vs polyrepo không phải về ngành công nghệ mà về tổ chức và team. Tôi đã thấy:
Startup dùng monorepo từ ngày 1, mở rộng thành 100 engineers, vẫn tốt nhờ culture/discipline
Công ty dùng polyrepo, chaos vì không có quy trình shared library management
Hybrid model là lựa chọn thực dụng nhất: cores/utils ở monorepo, customer-facing services ở polyrepo
Công cụ hỗ trợ ngày nay (Nx, Turborepo, Bazel, Gradle) đã loại bỏ hầu hết "gotchas" của monorepo, miễn là bạn có discipline về ci/cd infrastructure.
---
Chọn monorepo hay polyrepo, cái quan trọng là chọn vì sao, rồi bắt tay vào infrastructure/tooling thích hợp—bước này là nơi nhiều team hay bỏ qua, và đó cũng là lúc bạn nên tìm kiếm guidance từ những nền tảng như Idflow Technology để có roadmap rõ ràng.
