「すべての製品用の1つの大きなVCSリポジトリ」組織モデルから「多数の小さなVCSリポジトリ」モデルへのスムーズな移行を実現する方法
いくつかのVCSシステムのリポジトリに保持されている製品のコードベースが、そのコードベースがほぼ間違いなくいくつかの製品を含んでいると見なされるポイントに進化するという一般的なシナリオです。それぞれが単一の製品専用の複数のVCSリポジトリにコードベースを分割すると、いくつかの利点を活用できます（以下の肥大化リポジトリモデルよりもVCSリポジトリごとに製品を持っている利点を参照）。技術的な面では、ほとんどのVCSがこの操作をサポートしているため、コードベースの分割はかなり簡単な手順です。ただし、この分割により、自動化されたテスト、継続的な配信、サービスの統合または監視に関連するエンジニアリングの問題が発生する可能性があります（分割によって発生した問題を参照してください）。）したがって、このような分割の実行を計画している組織は、この移行をできるだけスムーズに、つまり、配信を中断せずにパイプラインを監視する方法を知る必要があります。これの最初のステップは、おそらくプロジェクトの概念と、モノリシックコードベースでの分割の詳細を理解することです。 この質問への回答では、私は見たいです： 製品とは何かを実際に定義する試み。これは、既存のコードベースで製品を実際に描写するための実用的な基準を提供します。 この作業定義に従って、実際に分割を実行する計画を作成します。コードベースがContinuous-IntegrationおよびContinuous-Deliveryを実装する完全に自動化されたsdlcによって処理されるという単純な仮定を立てることができます。つまり、各ブランチは現在のコードベースに実装された自動化されたテストスイートによって検証され、各「マジック」ブランチにマージされるたびに、テストおよびデプロイされる製品アーティファクトが生成されます。（製品のアーティファクトは、たとえばソースtarball、ドキュメント、バイナリソフトウェアパッケージ、Dockerイメージ、AMI、unikernelです。） そのような計画は、それを回避する方法を説明すれば満足です 分割によって提起された問題 自動化されたテスト手順は、既存のモノリシックリポジトリとスプリットリポジトリにどのように関連していますか？ 自動化された展開手順は、既存のモノリシックリポジトリと分割リポジトリにどのように関連していますか？ 自動展開手順自体のコードはどこに保存されていますか？ 保存されたインフラストラクチャ、監視、および高可用性戦略はどこにありますか？ 開発者が一度に1つのコードベースのみを必要とすることを保証する方法（ただし、他のコードベースのアーティファクトを使用可能）。 git-bisectのようなツールはどのようにできますか 限界メモ：肥大化したリポジトリモデルよりもVCSリポジトリごとに製品を持つことの利点 特定の製品のコードベースを保持するいくつかの小さなリポジトリがあると、「肥大化したリポジトリ」アプローチに比べて次の利点があります。 肥大化したリポジトリでは、製品が不安定なときにリリースをロールバックすることは困難です。これは、履歴が他の製品履歴と混在しているためです。 肥大化したリポジトリでは、プロジェクトの履歴やプルを確認するのが難しく、小さなリポジトリでは、この情報を読む可能性が高くなります。（これは、svnとは異なり、サブツリーをチェックアウトできないgitのようなVCSに固有の場合があります！） 肥大化したリポジトリを使用すると、開発時にさらに多くのブランチダンスを行う必要があります。N個のリポジトリがある場合、N個のブランチで並行して作業できます。リポジトリが1つしかない場合は、1つのブランチでしか作業できません。または、処理が面倒な作業コピーがたくさんあります。 いくつかの小さなリポジトリを使用すると、ログはプロジェクトのヒートマップを提供します。開発チームの知識普及のプロキシとして使用することもできます：3か月間レポXにコミットしなかった場合、レポXに取り組んでいるチームに私を割り当てて、開発を常に把握しておくとよいでしょうそのコンポーネントで。 小さなリポジトリを使用すると、コンポーネントの明確な概要を簡単に取得できます。すべてが単一の大きなリポジトリに格納されている場合、各コンポーネントの輪郭を示す明確なアーティファクトはなく、コードベースは泥の大きな塊に向かって簡単にドリフトできます。 小さなリポジトリにより、コンポーネント間のインターフェイスで作業する必要があります。しかし、私たちは良いカプセル化を望んでいるので、これはとにかくやるべき仕事なので、私はこれを小さなリポジトリの利点として数えます。 いくつかの小さなリポジトリを使用すると、複数の製品所有者を持っている方が簡単です。 いくつかの小さなリポジトリを使用すると、完全なリポジトリに関連し、自動的に検証できる単純なコード標準を簡単に作成できます。