web-dev-qa-db-ja.com

monorepo-複数の大規模な会社規模のプロジェクト用の単一のmonorepo

進む前にいくつかアドバイスが必要です。

マーケットプレイス製品のようないくつかの大規模なプロジェクト、およびいくつかのドメイン固有の製品とライブラリを構築したいと考えています。製品は関連している場合と関連していない場合がありますが、ライブラリを共有している場合があります。各製品は自社の会社である可能性が非常に高くなります（例：市場]）。

私はmonoreposを使用するためのものです。欠点と同じくらい多くの利点があります。 Pro-monorepoポイントについては、 モノリシックバージョン管理の利点danluu.com で、および記事の関連リンクで説明されています。

モノレポが必要だと思う理由—モノレポの長所について読みましたが、主に次のことに焦点を当てています。

  • クローズドソースコードの共有。製品とプロジェクトは内部（クローズドソース）ライブラリを共有します。クローズドソースの依存関係をローカルで利用できるため、コード共有が簡単になります。プロジェクトベースのリポジトリでは、ビルドに適切なツールが必要です。複数のリポジトリを使用してクローズドソースの依存関係を管理するためのツールが見つからないため、この要件を回避しようとしています。

モノレポが問題になる理由

  • スケーリングできない。
  • 大きな問題なしに変更をロールバックできない。
  • 機密コードを非表示にできません。製品とプロジェクトは単一のリポジトリを共有するため、1つの製品のコードが公開されます。

ご質問

  • いくつかのクローズドソースの大規模プロジェクトをmonorepoで管理するためのベストプラクティスは何ですか？
  • これらの大規模プロジェクトを同じリポジトリに置くのは賢明でしょうか（そして正気ですか）。

みんなありがとう

gitrepositorylarge-scale-project
7
eurekasfray

大規模な複雑さを管理するために、ジュリアスシーザー以来の勝利の原則は、「 Divide et impera "、英語の分割統治（または分割統治）です。この原則は、政治帝国とソフトウェア帝国に適用されます。

ソフトウェアエンジニアは帝国を征服するつもりはないため、これを別の言い方で呼びます。この原則の主なバリアントは 懸念の分離 、 componentization および カプセル化 （情報を隠すという意味で、成分）。これらの原則はすべて、独立した疎結合パーツを構築する方が簡単であり、必要に応じてブラックボックスを組み立てて、詳細や予期しない相互作用や依存関係を失うことなく、より高い価値を実現するという事実に基づいています。

いくつかの独立したリポジトリを採用することで、さまざまな参加チームがニーズに最適な手順を使用できるようにし、さまざまなリリーススケジュールを管理できるようになります。また、さまざまなコンポーネントを効率的に活用するために、さまざまなコンポーネントを販売または下請けすることもできます（例：オープンより一般的なライブラリを調達しますが、それでも他のより具体的な製品を管理できます）。

このすべて（およびモノリスに関連する他の多くの課題）は、ルールよりもなぜ モノレポが最近の例外である かを説明しています。あなたの選択を再考することを強くお勧めします。

4
Christophe

問題としてリストしたものに少し焦点を当てます。

スケーリングできない

Monorepoは単一のリポジトリではなく、モノリシックな方法で一緒に管理されるリポジトリのコレクション（必要な数だけ、場合によっては異なるバージョン管理システムを使用する）であり、単一のリポジトリとして表示されます。 。バージョン管理システムからのスケーラビリティは問題ではありません。

単一のリポジトリの使用をまだ検討しているので、コードベース全体でワークスペースをプルすることがサイズの問題で問題になる数少ないケースの1つではないと思います。そのような場合、製品を構築する革新的な方法が必要になります。

一部のモノリポジトリは、スパース操作をサポートしています-ワークスペースには、コードベースリポジトリのサブセットのみが含まれます。 Expanding Contracting Monorepos も参照してください。

大きな問題なしに変更をロールバックできない。

モノリシック管理のため、これはまったく問題ではありません-関係する各リポジトリを正しいバージョンに一貫してロールバックする必要がある、monorepoバージョンを単にロールバックします。

機密コードを非表示にできません。製品とプロジェクトは単一のリポジトリを共有するため、1つの製品のコードが公開されます。

繰り返しになりますが、単一のリポジトリではありません。

そして今、質問です。

いくつかのクローズドソースの大規模プロジェクトをmonorepoで管理するためのベストプラクティスは何ですか？

Donnoについてベスト、人によって意見は異なります:)私は、1,000を超えるリポジトリを持つ（カスタム）モノリポジトリでの広範な経験から、多くのチームや組み込み製品（膨大な量のコードを共有する）にサービスを提供していると話しています。

  • monorepoから個々のリポジトリでの独立した開発を阻止します。monorepoレベルで動作する適切なCI/CDシステムを使用して、すべてが一貫してmonorepoを通過する必要があります。
  • トランクベースの開発

これらの大規模プロジェクトを同じリポジトリに置くのは賢明でしょうか（そして正気ですか）。

同じレポではおそらくありません。モノレポでは、私見はい-あなたはすでに利点を知っています。

1
Dan Cornilescu