私たちはモノレポを使うべきですか？
私のチームはSubversionからgitへの移行を計画しています。 3つのアプリケーションをサポートしています... 1つは主に内部ユーザー用、1つは企業の「パートナー」用、1つはエンドユーザー用です。これらのアプリケーションはコードを共有し、Webサービスとメッセージキューイングを使用して相互に通信します。彼らは異なるリリーススケジュールを持っています。
現在、それぞれに個別のSubversionリポジトリがあります（3つのリポジトリ）。 Subversionの「外部」機能を使用して、メッセージキューの「契約」を含むコードを共有します。
Gitに移動するときに3つのリポジトリを保持するか、サブモジュールまたはその他のリポジトリ共有技術を使用するか、またはモノリポジトリを採用するかを決定するにはどうすればよいですか？
私の2セント：それらを別のリポジトリに配置します。
- 変更を追跡する方が簡単です（履歴、非難...）
- さまざまなリリースサイクル（タグ付け、バージョンの分岐など）を処理する方が簡単です。
- 扱いが簡単です（マージが少なく、ブランチが少なく、ファイル/他のプロジェクトからの依存関係がありません...）
...あなたの「共有コード」については、それを独自のライブラリー、独自のリポジトリーに配置します。または、単にインターフェースに関するものであれば、あるプロジェクトを別のプロジェクトの依存関係として宣言します。
TL; DR：私は政府のクライアントのために働いているコンサルタントです。一部のパッケージにはサブモジュールを使用しています。すぐにイライラするようになっています。パッケージをbeingと考えてブランチしてコミットすることに慣れている場合、おそらく3つのリポジトリ+サブモジュールを使用することはそれほど大きな問題ではありません。
とはいえ、物事が成長し進化し始めたら...
これはより個人的な好みの質問のようです。私はそれが2つの主要な事柄に帰着すると思います（私は現在これを自分で行うことを調査しているため）.
- 情報アーキテクチャ。
- コード推進戦略。
- プライベートモジュールとパブリックモジュール。
私が検討しているプロジェクトは、Laravelを使用したモノリシックアプリケーション（この用語は本当に嫌いです）として始まりました。それが成長するにつれて、私はサービスに割り込んで、それをフォルダーに入れましたwithin包括的なアプリケーション：
- /app
- /app-internal-packages
その後、プロジェクトは、Laravelアプリケーションに実際にはカスタムコードが含まれていなかったため、すべてのサービスを個別のモジュールにプルしました。一部はパブリックと一部のプライベートです。
これはかなりうまくいきましたが、ローカルで開発するときに、Packagistをすばやく模倣する（または何か面白いことをする）方法が必要になりました。さらに、公開リポジトリと非公開リポジトリでComposer（PHPのパッケージマネージャー））を使用することに関して、適切なドキュメントはそれほど多くありません...少なくとも私の頭では正気ではありません。独自のチケットのセットがあり、ユーザーはGitHubにチケットを配置するサービスを知らないでしょう...うまくいけば、アイデアがわかります。リポジトリを分離するcanで、特定の状況で機能します。これが私たちが現在持っているものです-表記は[PrR] = Private Repoおよび[PuR] = Public Repo（「サイト」を「アプリケーション」に変更してください）：
プライベートリポジトリ：
- サイト1
- サイト2
- サイト3
- サイト4
- 内部ポイントシステム
- ニュースレターシステム
- トレーナーシステム
- 会議システム
公開レポ：
- 認証パッケージ
- ポリシー表示システム
- uIスタイルとインタラクションパッケージ
- 支払いシステム
- プロファイルシステム
- 超ユニバーサルコード
- uiパッケージ
- マークアップビルダー
- ポリシー文書
- イベント登録
一部のパブリックリポジトリについては、プライベートに保つのが非常に煩わしい（またはコストがかかる）ため、パブリックにしか公開しないように設計し直しました。
もちろん、4つのサイトすべてがそのコードを共有できるという利点があります。しかし、コードプロモーション戦略により、私はその状況の現実に疑問を持ち始めています。基本的に、同じスコープで2回使用される場合は、そのスコープの最高レベルに昇格させます（意味がある場合）。したがって、たとえば、super universal code開始内部サイトの1つ。それはそのサイトの最高レベル（より良い用語がないためにグローバル）に昇格され、その後、誰かが別のサイトでそれを望んだ。だから私たちはそこにそれをチャックしました。
移行を検討しているもの：
プライベートリポジトリ：
- サイト
- サイト1
- サイト2
- サイト3
- サイト4
- 内部ポイントシステム
- ニュースレターシステム
- トレーナーシステム
- 会議システム
そして、おそらくいくつかの公開リポジトリを非公開に戻します。サブモジュールやパッケージ管理について心配する必要はありません。コードを昇格しても、完全に別のリポジトリに移動するわけではありません。ローカル開発を行う場合、ビルド手順は必要ありません。すべてのアプリの最新バージョンの起動はgit pullおよびすべてのサイトで可能なパブリックパッケージの更新。また、各ドメイン名は、サイトディレクトリの1つの内部のサブフォルダをポイントするだけです。
言い換えれば、monorepoルートを使用することには多くのメリットがあります。あなたが考えているルートに行くことには多くの利点があります。そして、質問にはもう少し詳細がありますが、コーチとコンサルタントとして、私は標準的な答えやアドバイスをするのに十分だとは思いません。