モノリポジトリ：しないでください

翻訳者から：こんにちは、Habr！ はい、これはモノリポジトリの長所と短所に関する別の記事です。 モノリポジトリの使用方法、mavenからbazelへの切り替え方法、およびその結果についての記事を書くつもりでした。 しかし、私がそれについて考えている間に、Lyftの開発者から素晴らしい記事が出てきたので、それを翻訳することにしました。 私は記事への私の追加、および続編としてのバゼルの経験を公開することを約束します。

私たちは2019年の新年度にあり、「Monorepository」にすべての組織のソースコードを保存することの利点（またはその欠如）について、もう1つの議論をする準備ができています。 このアプローチに慣れていない人にとっては、バージョン管理システムの単一のリポジトリにすべてのソースコードを保存するという考え方です。 もちろん、別の方法として、ソースコードをいくつかの独立したリポジトリに保存し、通常はそれらをサービス/アプリケーション/ライブラリの境界に沿って分割します。

この投稿では、このアプローチを「ポリリポジトリ」と呼びます。

ITの巨人の中には、Google、Facebook、Twitterなどを含む単一のリポジトリを使用しているものがあります。 もちろん、このような評判の良い企業がモノリポジトリを使用している場合、このアプローチのメリットは非常に大きいはずであり、私たち全員が同じことをすべきでしょう。 いや！ 記事のタイトルにあるように、「モノリポジトリを使用しないでください！」 大規模な場合、モノリポジトリはポリリポジトリが解決するのと同じ問題をすべて解決しますが、同時にコードの強力な一貫性を引き起こし、バージョン管理システムのスケーラビリティを高めるために信じられないほどの努力を必要とします 。

したがって、中長期的には、モノリポジトリは組織的な利点を提供しませんが、会社の最高のエンジニアには心的外傷後症候群（Gitパフォーマンスに関するよだれと首尾一貫しないつぶやきの形で現れます）を残します。


余談：「大規模に」とはどういう意味ですか？ この質問に対する単一の答えはありませんが、 このことについて私に尋ねるはずです。フルタイムのコードを書いている開発者は約100人いるとしましょう。

単一リポジトリの理論的な利点と、複数リポジトリに使用されるツールなしでは達成できない理由（またはfalse）

理論上の利点1：簡単なコラボレーションとコード共有

モノリポジトリの支持者は、すべてのコードが同じリポジトリにある場合、コードの重複の可能性は低く、異なるチームが共通のインフラストラクチャで連携する可能性が高いと主張しています。

ここに、中規模のモノリポジトリについての厳しい真実があります（そして、これはこのセクションでは絶えず聞こえます）：開発者が自分のワークステーションにすべてのリポジトリコードを保持したり、grepなどのユーティリティを使用してコードベース全体を検索したりするのは、すぐに非現実的になります したがって、スケーリングを必要とするモノリポジトリは、次の2つのことを提供します。

1）コードの一部のみをローカルに保存できる仮想ファイルシステムのようなもの。 これは、Googleの内部G3ツールまたはMicrosoftのGVFSを使用して、このモードをネイティブにサポートするPerforceなどの独自のファイルシステムを使用して実現できます。

2）ソースコードのインデックス作成/検索/表示のための、サービスとして（サービスとして）洗練されたツール。 なぜなら すべてのソースコードをワークステーションに検索可能な状態で保存する開発者はいません。コードベース全体でこのような検索を実行できることが重要になります。

開発者は各時点でソースコードのごく一部にしかアクセスできないという事実に基づいて、モノリポジトリの一部をダウンロードするか、いくつかの独立したリポジトリをダウンロードするか、少なくとも何らかの違いがありますか？ 違いはありません 。

インデックス作成/検索/ブラウジングなどのコードのコンテキストでは、このような仮想ツールは複数のリポジトリを簡単に検索し、結果を組み合わせることができます。 実際、これはまさにGitHubでの検索の仕組みであり、 Sourcegraphなどのより洗練された検索およびインデックス作成ツールでもあります。

したがって、大規模なコードの共同作業の観点から、開発者はいずれの場合もコードベースの一部のみで作業し、より高レベルのツールを使用することを余儀なくされます。 コードが単一のリポジトリに格納されているか、いくつかの独立したリポジトリに格納されているかにかかわらず、問題は同じ方法で解決され、コードでの共同作業の有効性はエンジニアリングコードのみに依存し、ソースコードの格納方法には依存しません 。

理論上の利点2：1つのアセンブリ/依存関係管理なし

次の議論は、通常、単一リポジトリの支持者によって引用されていますが、単一の単一リポジトリにすべてのコードを保存すると、依存関係を管理する必要がなくなります。 すべてのコードが同時に収集されます。 これは嘘です！ 大規模な場合、誰かがバージョン管理システムに変更をコミットするたびに（または、さらに重要なことに、新しいブランチまたはプルリクエストが作成されたときにCIサーバーで）すべてのソースコードを再構築し、すべての自動テストを実行する方法はありません。 この問題を解決するために、すべての大規模なモノリポジトリは独自の複雑なビルドシステム（たとえば、GoogleのBazel / BlazeやFacebookのBuck ）を使用します。これは、変更とその依存ブロックを監視し、ソースコードの依存関係グラフを構築するように設計されています。 このグラフを使用すると、アセンブリの結果とテストの効果的なキャッシュを整理できるため、変更とその依存関係のみが再アセンブリとテストを必要とします。

また、 収集されたコードは最終的にデプロイされる必要があります。ご存じのように、すべてのソフトウェアを同時にデプロイすることはできません。すべてのアセンブリアーティファクトを制御して、必要に応じてアーティファクトをやり直します。 本質的に、これは、モノリポジトリの世界でさえ、コードの複数のバージョンが同時に存在する可能性があることを意味し、慎重に監視および調整する必要があります。

モノリポジトリの支持者は、アセンブリ/依存関係を追跡する必要性を考慮しても、これは依然として否定できない利点があると主張します。 単一のコミットは、全世界の完全な状態を表します。 依存関係グラフが既に存在することを考えると、この利点はかなり物議を醸すと思います。このグラフの一部として各独立リポジトリのコミット識別子を含めるのは非常に簡単なタスクのようで、実際、Bazelは複数の独立リポジトリと1つのリポジトリモノリポジトリ。開発者から基礎レベルを抽象化します。 さらに、複数の独立したリポジトリの依存ライブラリのバージョンを一度に自動的に更新し、この部分のモノリポジトリとポリリポジトリの違いを平準化するような自動リファクタリングツールを実装するのは簡単です（詳細は後述）。

最終結果として、大規模なアセンブリ/展開の現実は、モノリポジトリとポリリポジトリの大部分で同じです。 ツールに違いはありません 。 開発者がコードを作成するためのものではありません 。

理論上の利点3：コードリファクタリングは単純なアトミックコミットです

最後に、単一リポジトリの支持者が言及する最後の美点は、1つのリポジトリが検索の容易さのためにコードリファクタリングを簡単にするという事実と、1つのコミットがリポジトリ全体に及ぶという考えです。 これにはいくつかの理由があります。

1）上記のように、大規模な場合、開発者は自分のローカルマシンでコードベース全体を編集または検索することはできません。 したがって、誰でもリポジトリ全体を自分自身に簡単に複製し、grep / replaceを実行するだけのアイデアは、実践するのがそれほど簡単ではありません。

2）複雑な仮想ファイルシステムの助けを借りて、開発者がコードベース全体を複製および編集できると仮定した場合でも、これはどのくらいの頻度で発生しますか？ 共有ライブラリーの実装のバグを修正することについては話していません。この状況は、単一のリポジトリーの場合と複数のリポジトリーの場合（上記のような同様のビルド/デプロイメントシステムを想定）で等しく処理されるためです。 ライブラリAPIの変更について話しているのですが、このライブラリが呼び出される場所で多くのコンパイルエラーが発生します。 非常に大規模なコードベースでは、基本的なAPIを変更することはほとんど不可能です。これは、マージの競合によりプロセスが再度開始される前に、関係するすべてのチームによってプレビューされます 。 開発者には2つの本当の可能性があります：彼はあきらめてAPIの問題の回避策を考え出すことができます（実際には、これは私たち全員が望んでいるよりも頻繁に起こります）、または彼は既存のAPIをそらし、新しいAPIを書いてから長い時間をかけてコードベース全体で古いAPIへのすべての呼び出しを痛々しいほど更新します。 いずれにしても、 これはpolyrepositoryの場合とまったく同じプロセスです 。

3）サービス指向の世界では、アプリケーションは多くの疎結合コンポーネントで構成されており、何らかのタイプのよく記述されたAPIを使用して相互作用します。 大規模な組織では遅かれ早かれ、ThriftやProtobufなどのIDL（インターフェイス記述言語）を使用するようになり、タイプセーフなAPIを作成して下位互換性のある変更を行うことができます。 前のビルド/デプロイセクションで説明したように、 コードを同時にデプロイすることはできません 。 数時間、数日、さらには数か月の期間にわたって展開できます。 したがって、開発者は、変更の下位互換性を考慮する必要があります。 これは現代のソフトウェア開発の現実であり、多くの人が無視したいのですが、無視することはできません。 したがって、サービスに関しては（APIライブラリとは対照的に）、開発者は上記の2つのアプローチのいずれかを使用する必要があります（APIを変更したり、廃止サイクルを経たりしないでください）。 これは、monorepositoryとpolyrepositoryの両方でまったく同じです 。

大規模なコードベースのリファクタリングといえば、多くの大規模な組織が最近Facebookからリリースされたfastmodなどの自動化されたリファクタリングツールを開発しています。 いつものように、このツールは1つまたは複数の独立したリポジトリで簡単に機能します。 Lyftには、まさにそれを行う「リファクタラー」と呼ばれるツールがあります。 fastmodのように機能しますが、プルリクエストの作成、ステータスレビューの追跡など、複数のリポジトリにわたる変更を自動化します。

モノリポジトリのユニークな欠点

前のセクションでは、モノリポジトリが提供するすべての理論上の利点をリストし、それらを活用するには、ポリリポジトリのツールと変わらない信じられないほど複雑なツールを作成する必要があることに注意しました。 このセクションでは、モノリポジトリの2つのユニークな欠点に言及します。

欠点1：強力な接続性とオープンソースソフトウェア

組織的には、単一リポジトリは密結合された脆弱なソフトウェアの作成を引き起こします。 開発者は抽象化でエラーを簡単に修正できると感じていますが、実際には、コードベース全体で変更を行おうとしたときに生じる不安定なアセンブリ/展開プロセスと人間/組織/文化的要因のためにできない。

ポリリポジトリのコード構造は、チーム/プロジェクト/抽象化/コード所有者間の明確で透明な境界を表し、開発者に相互作用インターフェースを慎重に検討するように強制します。 これは微妙ですが、非常に重要な利点です。これにより、開発者はより広く、長期的に考えることができます。 さらに、マルチリポジトリの使用は、開発者がリポジトリの境界を越えられないことを意味しません。 これが発生するかどうかは、発達文化のみに依存し、モノリポジトリまたはポリリポジトリのどちらが使用されるかには依存しません。

強力なバインディングは、ソースコードのオープンに関しても深刻な意味を持ちます。 企業がオープンソースソフトウェアを作成または使用する場合、マルチリポジトリの使用は必須です。 企業がプロジェクトをオープンソースでモノリポジトリ（ソースコードのインポート/エクスポート、パブリック/プライベートバグトラッカー、標準ライブラリの違いを抽象化する追加レイヤーなど）でレイアウトしようとしたときに発生する歪みは、生産的なコラボレーションにつながりません。コミュニティを構築するだけでなく、大きなオーバーヘッドを作成します

欠陥2：バージョン管理システムのスケーラビリティ

数百人の開発者、数億行のコード、および膨大な数のコミットのためにバージョン管理システムをスケーリングすることは、途方もない作業です。 5年前に（gitに基づいて）作成されたTwitterのモノリポジトリは、私がこれまで見てきた中で最も価値のないプロジェクトの1つでした。 git statusような単純なコマンドの実行には数分かかりました 。 リポジトリのローカルコピーが古すぎる場合、更新には数時間かかる可能性があります （その時点では、リポジトリのコピーを含むハードドライブを最新バージョンのコードを使用してリモートの従業員に送信することさえ行われていました）。 Twitterのデベロッパーをm笑するのではなく、この問題がいかに複雑であるかを示すためにこれを思い出します。 5年後、Twitterモノリポジトリのパフォーマンスは、Tillingチームの開発者が望んでいるものとはまだほど遠いと言うことができますが、これは彼らが懸命に努力したからではありません。

もちろん、過去5年間で、この分野でいくつかの開発が行われました。 Windowsの開発に使用されるMicrosoftのGit VFSは、バージョン管理システムをスケーリングするための前提条件として上記で説明したgitの実際の仮想ファイルシステムの出現につながりました（Microsoft Githubの購入により、このレベルのスケーリングはGiHubが企業クライアントに提供する機能のアプリケーション）。 そしてもちろん、GoogleとFacebookは引き続き機能するように内部システムに膨大なリソースを投資し続けていますが、これらはほとんど公開されていません。

前のセクションで説明したように、ツールキットがマルチリポジトリとまったく同じである必要がある場合、バージョン管理システムのスケーリングに関するこれらの問題を一般的に解決する必要があるのはなぜですか？ これには合理的な理由はありません。

おわりに

ソフトウェア開発でよくあることですが、最も成功しているソフトウェア企業を例に挙げて、これらの企業を成功に導いた原因を正確に理解せずにベストプラクティスを取り入れようとしています。 私の意見では、モノリポジトリはそのような場合の典型的な例です。 Google、Facebook、Twitterは、コードストレージシステムに膨大なリソースを投資して、ポリリポジトリに必要なソリューションと本質的に同じソリューションを考え出しましたが、 強力な連携を引き起こし、バージョン管理システムのスケーリングに多大な投資を必要とします 。

実際、大規模な場合、会社がコード、コラボレーション、強力なバインディングなどと連携して作業する方法 エンジニアリングの文化とリーダーシップに直接依存し、モノリポジトリが使用されているか、ポリリポジトリが使用されているかは関係ありません 。 開発者にとって、両方のソリューションは同じように見えます。 では、なぜ単一リポジトリを使用するのでしょうか？ しないでください！