大規模なコードベースのモノレポには何が必要ですか？

コードベースの特定のサイズから、まだGitを持っているでしょうか、それともより専門的なソリューションがありますか？

（コードベースの一部のみをチェックアウトするためにも）

Gitはmonoreposで機能しますが、いくつかの問題があります。

1. リポジトリ全体をチェックアウトする必要があります。
2. 履歴全体をフェッチする必要があります（通常-浅いクローンはオプションですが、通常、実際の開発作業では役に立ちません）。
3. 本来、すべてのディレクトリが存在する場合、誰でもすべてのディレクトリへの読み取り/書き込みアクセス権を持っています。

おそらく最も有名なmonorepoユーザーであるGoogleは、彼らのニーズに対応するためにPiperを開発しました。しかし、あなたはGoogleではないので、彼らのソリューションはおそらくあなたのものではありません。

monorepoの主な利点の1つは、グローバルにアトミックに変更できることです（つまり、同じコミットで呼び出し元と呼び出し先を変更できるため、多くのものをバージョン管理する必要がありません）。これを強化するには、リポジトリ全体の依存関係を追跡する統合ビルドシステムが本当に必要です。 Bazelは、GoogleのビルドシステムであるBlazeのオープンソース抽出であり、それを実行しようとします（ただし、それは若くて未成熟であり、Google以外の使用に必要な多くの機能がありません）。 パンツはツイッターからの類似したシステムです。

このようなアトミックな変更を行うときに大量のコードをビルドする場合は、ローカルマシン上では実行できないようにするビルドファームもおそらく必要です。同様に、更新時にすべてのテストを実行するには、強力なCIシステムが必要です。

答えは、両方のビットです。「use git」と「広大なコードベースを管理する」という制約を満たすために、Microsoft は新しいファイルシステムを開発しました（以前はSourceDepotと呼ばれるPerforceのバリアントを使用していました）。それはだ、オープンソースが、私はそれを使用してのない個人的な経験を持っていません。

なぜモノレポが必要なのですか？最も明白な理由は、アトミックコミットでAPIとそのAPIのすべての呼び出し元を変更できることです。またgit log、コードベース全体を検索できる利点もあります...

大規模なコードベースとは何かについての意見は異なります。100人のエンジニアがいる会社の話をしているとしたら、Gitはそれを処理できるはずです。Linuxカーネルのニーズに合わせて開発されましたが、それ自体は小さなプロジェクトではありません。

リポジトリの保存方法に関係なく、問題が発生する可能性があります。たとえば、大規模なJavaコードベースで作業していて、EclipseやIntelliJなどのツールを使用している場合、それらはより多くのメモリを使用し、通常は遅くなります。

一方、すべてのコードを一度に操作するオプション（たとえば、リファクタリングやソースコード変換を適用する場合）は、モノリシックリポジトリの主な利点の1つです。

特殊なツールが必要かどうかを尋ね、特定のコードサイズを増やすと、答えは「はい」になります。間違いなく世界最大のC ++コードベースを持つGoogleによると、利用可能なすべてのツール（オープンソースまたは商用）は要件を満たしていませんでした。彼らは最終的にPiperと呼ばれる社内システムを開発することになりました。

• Googleが何十億行ものコードを単一のリポジトリに保存する理由
• Googleが使用しているバージョン管理システムとその理由を教えてください。

私が正しく理解していれば、monorepoの「必要性」は、複数の緩やかに関連するコンポーネント/サブプロジェクトを含むソフトウェアプロジェクトに適用される単一/一貫したバージョン管理スキームの基本的な必要性にすぎません。別々のリポジトリ。

同様に、必要に応じて、通常のソースリポジトリを使用して、それぞれ独自の独立した変更履歴を持つ多数のソースファイルに単一の一貫したバージョン管理スキームを提供する必要があります。

実際のモノレポソリューションを使用することは間違いなく1つですが、このニーズに対処する唯一の方法ではありません。

別の可能なアプローチは、個々のプロジェクトコンポーネントリポジトリのそれぞれの正確なバージョンを含む1つ以上のマニフェストファイルを含む包括的なプロジェクトリポジトリを使用することです。

コンポーネントリポジトリのバージョンが独立した非アトミックコミットによって変更されている場合でも、関連するすべてのコンポーネントリポジトリバージョンの変更をアンブレラリポジトリのマニフェストファイルへの単一のコミットに結合するだけで、プロジェクト自体を首尾一貫して管理できます。

このようなアプローチには、実際のモノレポソリューションへの移行に比べていくつかの利点があります。

• 既存のコンポーネントリポジトリを変更する必要はありません
• さまざまなリポジトリテクノロジーを備えたコンポーネントの混在をサポートできる
• 各コンポーネントリポジトリは引き続き個別に開発および管理できます
• プロジェクトコンポーネントの追加/削除はほとんど簡単です
• サードパーティ（アップストリーム）コンポーネントの統合は非常に簡単です
• プロジェクト履歴は、個々のコンポーネントリポジトリの変更に関するすべての詳細で汚染されることなく、よりクリーンに保つことができます（通常、他のコンポーネントには関係ありません）。
• 単一のリポジトリのサイズ/パフォーマンス/スケーラビリティについて心配する必要はありません。ソリューション自体は非常にスケーラブルです。