モノレポなライブラリ群をCICDしたくて色々試した話 2023.01 .NETラボ 

誰？ Takas(@DevTakas) Angular / Azure / .NET Core / Azure DevOps / Microsoft Graph Microsoft MVP M365 Development 

誰？ ブログやってます http://takasdev.hatenablog.com/ 「はまったりひらめいたり…とか…」 

本日のゴールとおしながき 1. モノレポとマルチレポ 2. ライブラリの開発でマルチレポしてたときの課題 3. NxとTurborepoについて 4. モノレポ構成のライブラリとCI/CDを実装しよう 5. まとめ 

1. モノレポとマルチレポ 

1. モノレポとマルチレポ • モノレポ • 明確に定義された関係を持つ複数のプロジェクトを含む単一リポジトリ • 言語やフレームワークが異なるものが同一のリポジトリに入ってたりする • 「関係を持つ」集合であることが重要な要素 • 例えばサービスのひとかたまり • マルチレポ • ポリレポと呼ばれたりする • モノレポの逆 モノレポとマルチレポ(ポリレポ) 

1. モノレポとマルチレポ • モノレポ • メリット • サービスで固まっているので関連するリソースが明確 • テスト時に依存するものがわかるので統合的なテストも容易 • デメリット • CIやプロジェクト管理が複雑になりがち • 変更が巨大になりがち（諸説ある） • ポリレポ • メリット • CIやプロジェクト管理が楽 • 単一のリソースであればテストが容易に開始できる • デメリット • 依存するリソースが分かりづらい(もしくはわからない) • 上記のため変更の波及先が把握しづらい(統合的にテストをし辛い) モノレポとマルチレポのメリットとデメリット 

2.ライブラリ群の開発でマルチレポしてたときの課題 

2.ライブラリの開発でマルチレポしてたときの課題 • 変更とかデプロイの容易性をあげたいとかそういう理由でマルチレポ • 単一のライブラリの変更が他のライブラリに影響与えるとか避けたい • CIを複雑じゃなくして変更に強くしたい • peerDependencyで関係性は把握できている • ライブラリだし統合的にテストをするとかない？とも考えていた 現在のとあるJS(Angular)ライブラリの構成 

2.ライブラリの開発でポリレポしてたときの課題 • バージョンアップの手間の多さとハードルの高さ • 薄かろうが関係性はあるのでボトムから順にアップデート • フレームワークアップデート処理をライブラリごとにしないと…？ • ライブラリ内で関連あったら結局統合的にテストしなきゃ… • ライブラリ増えてきたら依存関係の把握が面倒になってきた… 現在のとあるライブラリの構成の問題点 と、いうわけでモノレポ構成を試してみることに 

2.ライブラリの開発でポリレポしてたときの課題 • CIの複雑化と単一リポジトリ実行時間の増加 • 変更があったライブラリだけ対象になんやかんやしてほしい… • 変更の検知をどうする？ • ビルドコマンドの実行をどのように場合分けする？ • 実行順序もコントロールしないといけない • ただ複数のCIが実行されてQueueが発生することはなくなる👍 モノレポにする問題点はなにか？ 

3.NxとTurborepoについて 

3.NxとTurborepoについて • モノレポに適した拡張ビルドシステム • 開発元はNx Cloud(Nrwl) • JS/TS/node.jsに特化 • ただし.NET用のnx-dotnetなどもある • Nx起点でプロジェクト構築すると色々と楽 • テストやLintツール勝手にいれてくれたりとか… • Gitの差分測定とそれを利用したBuildの高速化 • 差分があった領域のタスクのみ実行してくれる Nxとは 

3.NxとTurborepoについて • モノレポに適した拡張ビルドシステム • 開発元はVercel • JS/TS/node.jsに特化 • Gitの差分測定とそれを利用したBuildの高速化 • 差分があった領域のタスクのみ実行してくれる Turborepoとは 

3.NxとTurborepoについて • 雑に始めるならTurborepoは楽 • ただCIに持っていくと色々と面倒 • キャッシュをnode_modulesに持っていくのでリモートキャッシュしないと使えない • リモートキャッシュはVercelにサインアップすれば使えるが商用利用するには… • コンテナなど提供されているがセットアップがちと面倒 • Nxはプロジェクト構成がガッツリ変わるので好き嫌いは激しそう • 提供している機能は強力 • CI持っていっても素直に差分のみビルドしてくれたり • 標準で依存関係をグラフで表示してくれたり • 移行は楽だった印象(Angularの場合だが…) • そもそも@angular/cli開発元らしいのでその影響もあるかもしれない 使ってみた感想 

4.モノレポ構成のライブラリとCI/CDを実装しよう 

4.モノレポ構成のライブラリとCI/CDを実装しよう デモ 

5.まとめ 

5.まとめ • モノレポとマルチレポの違いについて • 一長一短あり。PJ運営方法やサービス構成に合わせて適切な方を選択 • 昨今の潮流からするとサービス単位でモノレポ構成のほうが良さげ？ • マイクロサービスで作られている必要はあるが • モノレポはビルドツールを導入してあげる • CIや依存関係のコントロール管理が楽になる • ビルドコマンドの実行順序とか・・・ • NxやTurborepoなど様々なビルドツールが存在する • 特色により最適なツールが異なるので技術選定は慎重に！ 

参考ページ • monorepo.tools • https://monorepo.tools/ • Monorepo開発のメリット vs デメリット • https://circleci.com/ja/blog/monorepo-dev-practices/ • https://turbo.build/ • https://nx.dev/