モノレポを選ぶ理由と、その代償

The case for monorepos, and what they cost youの意訳です。

複数のチームが同じコード、すなわちデザインシステム、共有API、一連のビジネスルールに依存しているとき、それらのコピーを別々のリポジトリにまたがって同期し続けるのは手間のかかる作業です。モノレポはその共有コードを1か所にまとめるので、修正は一度で済み、破壊的変更は3週間後にほかのチームのサービスで気づかないうちに壊れるのではなく、レビューの時点で失敗として現れます。

とはいえ、いったんすべてのチームが同じツリーに乗ると、質の悪い変更は全員の問題になります。そしてコードレビューは、1つの不注意なPRと、そのコードのすべての利用者との間に立ちはだかるものになります。

私はCodeRabbitでデベロッパーアドボケイトとして働いており、それ以前はCelonisでの大規模な移行を含め、組織がモノレポを導入したり、すでにあるモノレポをスケールさせたりするのを何年も手伝ってきました。この記事では、モノレポが価値を持つのはいつか、それを実用的にするツール、そして一度モノレポに踏み切ったあとに、CodeRabbitがそれをレビュー可能な状態に保つ方法を取り上げます。

モノレポ、ポリレポ、モノリス

モノレポでは、すべてのプロジェクトが1つのリポジトリに存在します。それらは異なる技術を使ってもよく、コードを共有してもしなくてもかまいません。これはGoogle、Meta、Microsoftが使っている方式であり、オープンソースのツールのおかげで、同じ構成がはるかに小規模なチームでも実用的になりました。これは、この記事で繰り返し立ち返ることになる移行の背後にある方式でもあります。

ポリレポでは、各チームに自分たちのリポジトリを与えます。つまり、100個のプロジェクトを持つ1つのリポジトリの代わりに、それぞれが独立して所有される100個のリポジトリを持つことになります。

モノリスはまったく別の種類のもので、リポジトリの構成ではなくアーキテクチャであり、単一のユニットとしてビルド・デプロイ・テストされるアプリケーションを指します。モノリスをモノレポの中で動かすこともできますし、ポリレポにまたがって分割することもできます。この言葉は、ソフトウェアがどうデプロイされるかを表すものであって、コードがどこに存在するかを表すものではないからです。

ポリレポがその真価を発揮するのは、チームが本当に独立していて、ほかの誰にも触れることなくデプロイできるときです。その失敗モードが分散モノリスです。これは、別々のリポジトリでありながら、依然として一緒にデプロイしなければならないもので、モノレポの調整コストだけを負い、その恩恵はまったく得られません。

小規模なチームを何年もモノレポから遠ざけていた反論が、ビルド時間でした。モノレポは変更が触れたものすべてを再ビルドするので、共有ロジックの一部分を編集するだけで、たとえその変更を使うのが1つだけであっても、デザインシステム、Webアプリ、モバイルアプリを再ビルドすることになりかねません。

ビルドキャッシュがそれを解決しました。NxやTurborepoのような無料のツールは、入力が変わらなかったプロジェクトをすべてスキップするので、ビルドは本当に自分が変更したものだけに触れます。キャッシュを保存する場所は必要ですが、GitHub Actionsはリポジトリあたり10GBを提供してくれるので、そこを超えて初めてS3バケットやリモートキャッシュのサービスに料金を払うことになります。かつては専任のプラットフォームチームを必要としたビルド速度の問題が、いまでは設定上の判断になりました。

モノレポが正しい選択となるとき

判断の決め手となる問いは、あなたのチームが本当にコードを共有しているかどうかです。プロジェクトが独立していて、それぞれ単独でデプロイするなら、ポリレポのほうがシンプルです。複数のチームが同じデザインシステム、ビジネスロジック、APIを保守しているなら、すべてを同期し続けてくれるのがモノレポです。

このパターンは、たいてい気軽に始まります。あるチームが単独で完結する何かをリリースし、やがてそれが成長して、デザインシステムやマイクロサービスをほかのアプリと共有し始めます。紙の上では、すべてが独立したままです。しかし請求はあとからやってきます。同じ共有コードのライブなバージョンをいくつも保守することになり、アップグレードのたびにそれらすべてをビルドして公開しなければならなくなるのです。

モノレポはまた、サービスをまたいだアトミックな変更が必要なときにも軍配が上がります。すべてのアプリが依存するマイクロサービスに破壊的変更を持ち込むとき、ポリレポでは修正がリポジトリ全体に散らばり、本番環境が壊れたあとにそれをロールバックすることは、影響を受けるすべてのチームを巻き込んだ調整の問題になります。モノレポでは、同じ変更が単一の履歴を持つ単一のコミットとして入ります。1回のリバートで、あらゆる場所でそれを取り消せます。

同じ論理が大規模なリファクタリングにも当てはまります。それはポリレポが行き詰まる場所です。あなたは、依存している変更をほかのチームがリリースするのを待って、ブロックされたまま待ち続けることになります。時間とともに、これは文化も形作り、同じユーティリティを5回も作り直す代わりに、共有コードを再利用するようチームを後押しします。

以前いた会社では、私のチームは1つの相互に連携した製品に取り組んでいましたが、ポリレポのもとでは、各チームが共有のデザインシステムに対して自分たちのフロントエンドを構築していました。Angularをアップグレードするには、各チームのリポジトリを1つずつ追いかける必要があり、それは惨めな作業でした。

数年をかけて、私たちは全員をNxのモノレポへと統合しました。すると、その変化は数字に表れました。リリースは、たまに行うものから週に40以上のアプリへと変わったのです。Angularのアップグレードや新しいツールの導入は、プロジェクトであることをやめて日常業務になり、内部ライブラリを通じたコード共有が、ようやく本来意図されたとおりに機能するようになりました。

これらはどれも、ポリレポが間違いだということにはなりません。むしろポリレポは、別の問いに対する答えなのであって、関連のないプロジェクトを無理やり1つのリポジトリに押し込めば、それ自体が問題を引き起こします。

ポリレポのほうが良い選択となるとき

ポリレポには本当の使い道があり、そのうちの1つは最初にはっきり述べておく価値があります。モノレポは複数運用できるので、「すべてを1つのリポジトリに置かない」ことは「プロジェクトごとに1つのリポジトリ」を意味しません。

チームがコードを共有せず、それぞれ独自のサイクルでリリースする、互いに関連のない製品を所有しているときは、切り分けておきましょう。そこではモノレポは何ももたらさず、別々のリポジトリのほうが、リリースのタイミングや顧客向けの変更履歴をすっきり保てます。

コンプライアンスが、この切り分けを譲れないものにすることもあります。政府の請負業者や、指名された人だけがコードに触れることを求める顧客にとっては、ほかのすべてから隔離されたリポジトリが最も適しているからです。オープンソース化がもう1つのよくあるケースで、専用の公開リポジトリがあれば、コードベースの残りの部分を引きずり込むことなく、外部の貢献者を迎え入れられます。

CodeRabbitでモノレポを健全に保つ

さて、あなたが決断を下し、モノレポに移行したとしましょう。ここで賭けの支払いがやってきます。あらゆる利点は、チームを同じツリーに置いたことから生まれました。そして、その同じ近さは、いまや1つの不注意なPRが下流の全員に届くことを意味します。忙しいモノレポでは、それを捉えるレビュアーは週に何十ものPRをさばいている人であり、人は物事を見落とします。

その上に、より新しい圧力がのしかかります。PRに含まれるコードのうち、チームの誰も書いていない割合が増えているのです。コーディングエージェントがそれを生み出し、レビュアーはいまや、自分が書いたのではなく、完全には理解していないかもしれないコードを評価しています。それは問いを「自分ならこう書いただろうか」から、より難しいもの、すなわち「これは実のところ何をするのか、そしてどこで壊れるのか」へと変えてしまいます。

CodeRabbitによるAIが書いたPRと人間が書いたPRの比較分析では、AIが生成した変更は平均しておよそ1.7倍多くの問題を抱えており、可読性の問題は3倍以上多いことが分かりました。モノレポでは、そのコードが全員の共有ロジックのすぐ隣に入るので、理解のギャップもまた共有の問題になります。

CodeRabbitは、繰り返しの多い最初のパスを引き受けるので、あなたのレビュアーはアーキテクチャと意図に注意を注げます。モノレポでは、いくつかの点で利用する価値があります。

• コードグラフを通じて変更を追跡し、破壊的なAPIの変更を、それが影響を与える呼び出し元と照らし合わせて、PRがマージされる前に指摘します。

• 各レビューを一般的な言葉による要約、ウォークスルー、アーキテクチャ図から始めるので、なじみのない変更に向き合うレビュアーは、それが正しいかどうかを判断する前に、それが何をするのかを見て取れます。

• パッケージをまたいでスタイルと規約を一貫させ、抜けているドキュメントを指摘します。そして、共有コードが最も速く駄目になっていく場所です。

• 50を超えるLinterやSASTスキャナをインラインで実行し、汎用的なチェックリストを当てはめるのではなく、時間をかけてチームのフィードバックから学びます。

これらはどれも、人間によるレビューを置き換えるものではありません。人間をより速くし、そうでなければ離れていってしまうチームの間でも、基準を保ってくれるのです。

コンテキストは、単一のツリーに限られるわけでもありません。ポリレポについては、Linked RepositoriesとMulti-Repo Analysisが、同じ推論を関連するリポジトリへと広げるので、APIスキーマで名前を変えたフィールドは、それを解析するサービスがたとえ別の場所に存在していても、それらと照らし合わせて浮かび上がります。それこそが、マイクロサービス、共有SDK、あるいは分割されたフロントエンドとバックエンドを持つチームにとって重要なことです。