Monorepoのすべて

xguru · 2022-02-28T11:50:12+09:00

Monorepoとは何か「複数の個別プロジェクトを、明確に定義された関係性を通じて1つのRepoに収めたもの」 Monorepo ≠ Monolith なぜやるのか？従来のPolyrepo（複数のRepoを使う方式）が選ばれていた理由は「チームの自律性（team autonomy）」にあった各チームが望むライブラリを選び、誰がコードに貢献し利用するかを決めることができる Polyrepoはコード共有が煩雑コードの重複が多い共有ライブラリでクリティカルなバグや大きな変更が発生した際のコストが高いプロジェクトごとに一貫しない開発ツールの使用 Monorepoは新しいプロジェクトを作成するオーバーヘッドがないプロジェクト全体にまたがるアトミックコミットすべてを単一のバージョン番号で管理開発者のモビリティ（プロジェクト間の移動） Monorepoツールが提供する機能と各ツールの比較 → Bazel, Gradle, Lage, Lerna, Nx, Rush, Turborepo ローカルキャッシュローカルタスクオーケストレーション分散キャッシュ分散タスク実行透過的なリモート実行影響を受けるプロジェクト/パッケージの検出ワークスペース分析依存関係グラフの可視化コード共有一貫したツール群コード生成プロジェクト制約と可視性認識の転換モノレポは、皆さんの「組織とコードに対する考え方」を変えます一貫性を加え、新しいプロジェクトを作るときや大規模なリファクタリングを行うときの摩擦を減らし、コード共有とチーム間コラボレーションを促進することで組織はより効率的に作業できるさまざまなソリューションがあるが、それぞれ目標が異なる Bazel (by Google) : “A fast, scalable, multi-language and extensible build system.” Gradle (by Gradle, Inc) : “A fast, flexible polyglot build system designed for multi-project builds.” Lage (by Microsoft) : “Task runner in JS monorepos” Lerna : “A tool for managing JavaScript projects with multiple packages.” Nx (by Nrwl) : “Next generation build system with first class monorepo support and powerful integrations.” Rush (by Microsoft) : “Geared for large monorepos with lots of teams and projects. Part of the Rush Stack family of projects.” Turborepo (by Vercel) : “The high-performance build system for JavaScript & TypeScript codebases.”

(monorepo.tools)

23 ポイント投稿者 xguru 2022-02-28 | 4件のコメント | WhatsAppで共有

Monorepoとは何か

「複数の個別プロジェクトを、明確に定義された関係性を通じて1つのRepoに収めたもの」
Monorepo ≠ Monolith

なぜやるのか？

従来のPolyrepo（複数のRepoを使う方式）が選ばれていた理由は「チームの自律性（team autonomy）」にあった
- 各チームが望むライブラリを選び、誰がコードに貢献し利用するかを決めることができる
Polyrepoは
- コード共有が煩雑
- コードの重複が多い
- 共有ライブラリでクリティカルなバグや大きな変更が発生した際のコストが高い
- プロジェクトごとに一貫しない開発ツールの使用
Monorepoは
- 新しいプロジェクトを作成するオーバーヘッドがない
- プロジェクト全体にまたがるアトミックコミット
- すべてを単一のバージョン番号で管理
- 開発者のモビリティ（プロジェクト間の移動）

Monorepoツールが提供する機能と各ツールの比較

→ Bazel, Gradle, Lage, Lerna, Nx, Rush, Turborepo

ローカルキャッシュ
ローカルタスクオーケストレーション
分散キャッシュ
分散タスク実行
透過的なリモート実行
影響を受けるプロジェクト/パッケージの検出
ワークスペース分析
依存関係グラフの可視化
コード共有
一貫したツール群
コード生成
プロジェクト制約と可視性

認識の転換

モノレポは、皆さんの「組織とコードに対する考え方」を変えます

一貫性を加え、
新しいプロジェクトを作るときや大規模なリファクタリングを行うときの摩擦を減らし、
コード共有とチーム間コラボレーションを促進することで
組織はより効率的に作業できる

さまざまなソリューションがあるが、それぞれ目標が異なる

Bazel (by Google) : “A fast, scalable, multi-language and extensible build system.”
Gradle (by Gradle, Inc) : “A fast, flexible polyglot build system designed for multi-project builds.”
Lage (by Microsoft) : “Task runner in JS monorepos”
Lerna : “A tool for managing JavaScript projects with multiple packages.”
Nx (by Nrwl) : “Next generation build system with first class monorepo support and powerful integrations.”
Rush (by Microsoft) : “Geared for large monorepos with lots of teams and projects. Part of the Rush Stack family of projects.”
Turborepo (by Vercel) : “The high-performance build system for JavaScript & TypeScript codebases.”

4件のコメント

kleinstein 2022-03-02

アプリケーションを開発して顧客ごとに導入していると、
ある顧客はこれ以上のアップグレードを望まないこともあれば、
ある顧客は自分たちだけの特別なバージョンを求めることもあります。

そのため、こうした顧客が増えてくると、
結局 Repository は何十もの顧客向けカスタムバージョンの branch で埋め尽くされます。
各 branch ごとに少しずつ異なるバージョンが入っています。

こういう状況で Monorepo の記事を見ると……本当に夢のような話に聞こえますね。笑

bbulbum 2022-02-28

ほとんどの状況で共有ライブラリは良い考えではないとトーバルズが言っていたのを思い出します。最近適用してみていますが、思ったより共有できる部分は少なく、ビルドシステムが絡み合う部分は大きいので、私としてはモノレポは期待したほど理想的なシステムではないのではないかと思います。

galadbran 2022-02-28

Subversion が主流だった時代にはごく当たり前のことだったのに、なんだか皮肉だなと強く感じます。
しかもフロントエンド開発に限定して語られているのも不思議です。
MS では Git も Subversion のように使えるよう仮想ファイルシステムを作ったのに、それが一般化しなかったのが残念ですね。

xguru 2022-02-28

なんだか最近は、技術が巡り巡っている感じがいっそう強いんですよね。
ああ、これって昔あまりよくなかったあれじゃない？と思うことがあって……長くやりすぎたのかな、なんて思います。しくしく