はじめに
ソース コードの編成方法によって、開発者のエクスペリエンス、CI/CD の複雑さ、チームのコラボレーションが決まります。この記事では、モノリポジトリとマルチリポジトリを比較し、適切なリポジトリを選択するためのガイダンスを提供します。
1. マルチリポジトリ
1.1 モデル
github.com/company/
├── product-service/ (repo riêng)
├── order-service/ (repo riêng)
├── cart-service/ (repo riêng)
├── product-mfe/ (repo riêng)
├── cart-mfe/ (repo riêng)
├── shell-app/ (repo riêng)
├── shared-ui/ (repo riêng, npm package)
└── shared-types/ (repo riêng, npm package)
1.2 利点と欠点
| 利点 | デメリット |
|---|---|
| 所有権を明確にする | 共有コードは管理が難しい (npm pub) |
| 独立した CI/CD | リポジトリ間の複雑な変更 |
| 小さいリポジトリ = 高速クローン | 依存関係のバージョンのドリフト |
| きめ細かいアクセス制御 | 一貫性を強制するのは難しい |
2. モノリポジトリ
2.1 モデル
github.com/company/platform/
├── apps/
│ ├── shell-app/
│ ├── product-mfe/
│ ├── cart-mfe/
│ └── order-mfe/
├── services/
│ ├── product-service/
│ ├── order-service/
│ └── cart-service/
├── packages/
│ ├── shared-ui/
│ ├── shared-types/
│ └── eslint-config/
├── turbo.json / nx.json
└── package.json (workspace root)
2.2 利点と欠点
| 利点 | デメリット |
|---|---|
| Shared code easily (internal packages) | 大規模なリポジトリ → クローンが遅い |
| Atomic cross-package changes | CI の複雑さ (影響を受ける検出) |
| 一貫したツールと構成 | 粗粒度のアクセス制御 |
| リファクタリングは簡単です | Build time long (need caching) |
3. 意思決定マトリックス
| 係数 | マルチリポジトリ | モノリポジトリ |
|---|---|---|
| チームの規模 | 50 人以上の開発者、多くのチーム | < 50 人の開発者、少数のチーム |
| 共有コード | あまり共有されていない | 多くの共有パッケージ |
| Deploy independence | ✅ ナチュラル | ✅ 影響を受けた検出を使用する |
| 横断的な変更 | ❌ 複数の PR | ✅ シングル PR |
| CI/CD | リポジトリごとの単純な | 複雑だが強力 |
| オンボーディング | 簡単 (1 サービス/リポジトリ) | 中 (大規模なリポジトリ) |
4. モノリポジトリツール
4.1 ターボレポ
// turbo.json
{
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", ".next/**"]
},
"test": {
"dependsOn": ["build"]
},
"lint": {}
}
}
# Build chỉ affected packages
turbo build --filter=...[origin/main]
# Build product-mfe và dependencies
turbo build --filter=product-mfe...
4.2 Nx
# Affected commands (chỉ build/test code thay đổi)
nx affected --target=build --base=main
nx affected --target=test --base=main
# Dependency graph
nx graph
4.3 主な機能
|特長 |ターボレポ | Nx | |----------|----------||-----| | 影響を受けた検出 | ✅ Git ベース | ✅ 依存関係グラフ | | リモート キャッシング | ✅ ヴェルセル | ✅ Nxクラウド | | タスク オーケストレーション | ✅ パイプライン | ✅ タスクグラフ | | コード生成 | ❌ | ✅ 発電機 | | プラグイン エコシステム |限定 |リッチ (React、Node など) |
5. コードの所有権 (CODEOWNERS)
# .github/CODEOWNERS
apps/product-mfe/ @team-product
apps/cart-mfe/ @team-cart
services/product-*/ @team-product
services/order-*/ @team-order
packages/shared-ui/ @team-platform
packages/shared-*/ @team-platform
turbo.json @team-platform
→ PR は、変更されたファイルに基づいてレビュー担当者を自動的に割り当てます。
6. 推奨事項
E-Commerce Platform (series này):
Mono-Repo (Turborepo):
├── apps/ (Shell + MFEs)
├── services/ (Microservices)
├── packages/ (shared-ui, shared-types, eslint-config)
└── infra/ (Terraform, K8s manifests)
Lý do:
- Nhiều shared code (UI, types, configs)
- Cross-cutting changes thường xuyên
- Lợi ích từ affected detection & remote caching
- Team size < 50 devs
概要
- マルチリポジトリ: 明確な所有権、シンプルな CI、ただしコードの共有は困難
- モノリポ: コードの共有が簡単、アトミックな変更、ツールが必要 (Turborepo/Nx)
- 影響を受ける検出 + リモート キャッシュには Turborepo/Nx を使用します
- CODEOWNERS モノリポジトリ内のコード所有権