モノレポはコードの共有とプロジェクトをまたがるリファクタリングをシンプルにし、ライブラリやマイクロサービスとしてマイクロフロントエンドの作成コストを大幅に下げます。モノレポを採用すると、大抵はデプロイの柔軟性が高まります。他のチームが知らないうちに私のコードを変更してしまう他のチームが私のアプリを壊すことができる、私の知らないうちに、しかもリリース直前に!この誤解は、リポジトリ設定だけでアクセスとパーミッションを制御することに起因します。多くのツールではフォルダごとに所有権を設定できることがほとんど知られていません。@bobこの設定の場合、あなたがアプリAを更新するプルリクを出したら、スーザンが承認する必要があります。アプリBのみを触る場合はボブが承認します。プルリクがAとBに触れる場合、スーザンとボブの承認が必要です。ちなみに、コードの所有権に関しては、より多くのコントロールが可能です。この図では:組織内には2つのチームがあります。いう共有ライブラリを作りました。あり、彼らはチームAがそれに依存することを望んでいません。チームAが依存してしまうと、チームはお互いに密になり、チームBは共有ライブラリを変更するたびにチームAへの影響を検討しなければならないからです。追加することは防げません。チームBが管理できないリポジトリなので、チームBがその変更を知ることができないのです。ほとんどのモノレポのツール(Nxを含む)では、ライブラリの可視性を的確な方法で定義できます。インポートしようとすると、このようになります:大きな泥団子になってしまうひとつのアプリケーションでさえ、なんとか管理しているのに、5つのアプリケーションを同じリポジトリにおいたら、誰もまったく理解できなくなるよ!この誤解は、同一リポジトリ内であれば、どのファイルでも他のファイルをインポートできるという事実から来ています。人々はコードレビュー中になんらかのルールを課そうとしますが、それらは明確な定義として長期間定着せず、依存関係がグチャグチャになってしまいます。みんな、知っているのです。サイズのプロジェクト(5万行ぐらい)を開き、メインコンポーネントとその周りの相互依存についての依存関係図を描きます。リポジトリを確認してみましょう。あなたは"予期しない"依存をたくさん見つけることになります。APIを持つライブラリを作ることができます。ライブラリはほんの数秒で作れてしまうので、たくさんのライブラリを作成するようになります。APIによってのみ相互依存します。すれば依存関係グラフの生成を自動化できます。アーキテクトがWikiに貼り付けた図は、すぐに時代遅れになりますが、依存関係グラフは正確かつ適切に更新されます。リポジトリ内のライブラリへメタデータを追加することで、それを基にした制約を定義することが可能です。プレゼンテーションコンポーネントがステートを管理するコードに依存できないことを静的に保証できます。モノレポにすることによって、多くの人々が考えていたことと逆のことが起きるのです。スケールしないCIに5時間もかかるなんて思った?すべてのコミットのたびに、すべてを再ビルド・再テストすると遅くなります。片手ぐらいのプロジェクトを超えてしまうとスケールすることはありません。前述のように、モノレポを使用すれば、影響を受けるものだけを再ビルド・再テストします。CIを何もいじらずに際限なくスケールするということではありません。リポジトリに多くの大きなアプリがあるなら、平均的なCI時間は早くなります。全アプリが依存する変更があった場合には、すべてを待たねばなりまん。そんなプルリクは稀でしょうが、スケールを得るためには複数台でCIを回すことを考えてもいいでしょう。gitは壊れますか?この懸念は根拠がないことではないです。リポジトリに100万のファイルがあった場合、Gitそのものを含め、あなたが愛用する多くのツールは動かなくなります。多くのモノレポには何千ものアプリはありません。1つの組織であれば1ダース(12個)ぐらいでしょう。数千のファイル、数百万行のコード。ツールは問題なく扱えるでしょう。マイクロソフトは膨大なレポジトリ数を前提としたスケーラブル版GitであるGVFSをリリースしました。近々にサポートするでしょう。本当の課題これまでに書いたことは誤解にもとづくものです。モノレポが完全という意味ではないです。モノレポも課題を抱えています。トランクベース開発モノレポと長期にわたるfeatureブランチは相性が悪いです。トランクベースの開発を取り入れるチャンスです。トランクベース開発への移行は一部のチームにとっては簡単ではありません。フィーチャートグルのような新しいプラクティスを採用する必要があるからです。私は、リポジトリのサイズに関わらず、トランクベース開発が高品質なコードと高ベロシティにつながると信じていますが、それでも何かしらの考慮は必要です。すべてのサービスが動作するわけではないモノレポはまだ主流ではなく、一部のサービスはうまく機能しません。単一デプロイアーティファクトや、リポジトリ単位でのカバレッジレポートが必要になるかもしれません。いえ、ほとんどの課題はなんとかなるでしょう。CIモノレポへ移行するには、継続的インテグレーションの方法を再考する必要があります。そもそも、1つのアプリをビルドしています、なんてことはないのです。変更によって影響を受けたものだけをビルドしているでしょう。ポピュラーなCIソリューション(Azure、Circle、Jenkins等)にはNxなどを組み込む十分な柔軟性がありますが、その方法を把握するのに時間がかかるかもしれません。あなたは100のライブラリから作り出された10のアプリをリファクタリングして、変更をコミットする前に、それらすべての動作を検証できます。してしまうことで、大規模な変更によって、より多くのことを考える必要がでて、物事をややこしくしてしまいます。共有ライブラリを変更した場合、それに依存するすべてのアプリケーションが影響を受けます。それが、破壊を伴う変更で、自動化もできていないなら、下位互換性がある変更をおこなわなくてはなりません。あなたは、2つのバージョンのパラメータ/メソッド/クラス/パッケージを作り、利用者が古いバージョンから新しいバージョンへ移行するのを助ける必要があります。まとめモノレポには次の利点があります:すべてにおいて現時点でコミットされたものが動きます。オープンソースで拡張可能なモノレポ用の開発ツールセットです。