「すべての製品用の1つの大きなVCSリポジトリ」組織モデルから「多数の小さなVCSリポジトリ」モデルへのスムーズな移行を実現する方法

いくつかのVCSシステムのリポジトリに保持されている製品のコードベースが、そのコードベースがほぼ間違いなくいくつかの製品を含んでいると見なされるポイントに進化するという一般的なシナリオです。それぞれが単一の製品専用の複数のVCSリポジトリにコードベースを分割すると、いくつかの利点を活用できます（以下の肥大化リポジトリモデルよりもVCSリポジトリごとに製品を持っている利点を参照）。技術的な面では、ほとんどのVCSがこの操作をサポートしているため、コードベースの分割はかなり簡単な手順です。ただし、この分割により、自動化されたテスト、継続的な配信、サービスの統合または監視に関連するエンジニアリングの問題が発生する可能性があります（分割によって発生した問題を参照してください）。）したがって、このような分割の実行を計画している組織は、この移行をできるだけスムーズに、つまり、配信を中断せずにパイプラインを監視する方法を知る必要があります。これの最初のステップは、おそらくプロジェクトの概念と、モノリシックコードベースでの分割の詳細を理解することです。

この質問への回答では、私は見たいです：

1. 製品とは何かを実際に定義する試み。これは、既存のコードベースで製品を実際に描写するための実用的な基準を提供します。

2. この作業定義に従って、実際に分割を実行する計画を作成します。コードベースがContinuous-IntegrationおよびContinuous-Deliveryを実装する完全に自動化されたsdlcによって処理されるという単純な仮定を立てることができます。つまり、各ブランチは現在のコードベースに実装された自動化されたテストスイートによって検証され、各「マジック」ブランチにマージされるたびに、テストおよびデプロイされる製品アーティファクトが生成されます。（製品のアーティファクトは、たとえばソースtarball、ドキュメント、バイナリソフトウェアパッケージ、Dockerイメージ、AMI、unikernelです。）

3. そのような計画は、それを回避する方法を説明すれば満足です

分割によって提起された問題

1. 自動化されたテスト手順は、既存のモノリシックリポジトリとスプリットリポジトリにどのように関連していますか？

2. 自動化された展開手順は、既存のモノリシックリポジトリと分割リポジトリにどのように関連していますか？

3. 自動展開手順自体のコードはどこに保存されていますか？

4. 保存されたインフラストラクチャ、監視、および高可用性戦略はどこにありますか？

5. 開発者が一度に1つのコードベースのみを必要とすることを保証する方法（ただし、他のコードベースのアーティファクトを使用可能）。

6. git-bisectのようなツールはどのようにできますか

限界メモ：肥大化したリポジトリモデルよりもVCSリポジトリごとに製品を持つことの利点

特定の製品のコードベースを保持するいくつかの小さなリポジトリがあると、「肥大化したリポジトリ」アプローチに比べて次の利点があります。

1. 肥大化したリポジトリでは、製品が不安定なときにリリースをロールバックすることは困難です。これは、履歴が他の製品履歴と混在しているためです。

2. 肥大化したリポジトリでは、プロジェクトの履歴やプルを確認するのが難しく、小さなリポジトリでは、この情報を読む可能性が高くなります。（これは、svnとは異なり、サブツリーをチェックアウトできないgitのようなVCSに固有の場合があります！）

3. 肥大化したリポジトリを使用すると、開発時にさらに多くのブランチダンスを行う必要があります。N個のリポジトリがある場合、N個のブランチで並行して作業できます。リポジトリが1つしかない場合は、1つのブランチでしか作業できません。または、処理が面倒な作業コピーがたくさんあります。

4. いくつかの小さなリポジトリを使用すると、ログはプロジェクトのヒートマップを提供します。開発チームの知識普及のプロキシとして使用することもできます：3か月間レポXにコミットしなかった場合、レポXに取り組んでいるチームに私を割り当てて、開発を常に把握しておくとよいでしょうそのコンポーネントで。

5. 小さなリポジトリを使用すると、コンポーネントの明確な概要を簡単に取得できます。すべてが単一の大きなリポジトリに格納されている場合、各コンポーネントの輪郭を示す明確なアーティファクトはなく、コードベースは泥の大きな塊に向かって簡単にドリフトできます。

6. 小さなリポジトリにより、コンポーネント間のインターフェイスで作業する必要があります。しかし、私たちは良いカプセル化を望んでいるので、これはとにかくやるべき仕事なので、私はこれを小さなリポジトリの利点として数えます。

7. いくつかの小さなリポジトリを使用すると、複数の製品所有者を持っている方が簡単です。

8. いくつかの小さなリポジトリを使用すると、完全なリポジトリに関連し、自動的に検証できる単純なコード標準を簡単に作成できます。

これは、本当の答えが実際には存在しない魅力的な質問です。質問をVCSのコンテキストに当てはめようとしたが、それ自体がインフラストラクチャの設計と実装計画に応じて自然にスケールアップしたことに感謝します。

しかし、私たちの多くはこの種の移行に取り組んでいるようです。そして、私は自分の経験と意見を共有したいと思います。

設計

インフラストラクチャとアーキテクチャを組み合わせて最新のソフトウェアを作成する必要があります。必要に応じて、密結合。これらの単語を使用するのは奇妙に聞こえるかもしれませんが、ここではコード自体については必ずしも話していません。つまり、それらは同じ設計図の一部でなければならないということです。雲が到着し、人々が彼らのためにソフトウェアを書き始めたとき、どれだけの人がそこに泥玉を置くことで、彼らはちょうど別の場所に同じ泥玉であることに気づきましたか？そして、彼らはおそらく今日、devopsで働いています。devopsはさまざまな人々にとって非常に多くの異なる意味を持つ単なる流行語であるため、devopsチームがすべてのアーキテクチャ会議に参加する場所を見てきました。自動化のみの他の場所。この種の変革を実現するには、そこに座る方法を戦わなければなりません。

信頼

一貫した履歴カットが存在しなければならないという意味で、移行は隔離された状態に保たれなければなりません。自信を持ってそれを承認し、赤いボタンを押しますか？

つまり、新しいVCS構造に対応するためにコードベースを変更する必要があり、開発中にコードベースをマージし続けることは非常に困難です。（この問題については、戦略を促進する可能性があります。後ほど開発の並列化に役立つ一般的な戦略について説明します）。

まあ私は唯一の方法は行動テストであり、同じコードの行動テストを起動して古いコードベースと新しいコードベースを検証する必要があります。ここでは、アプリケーションが期待どおりに動作することを確認していませんが、移行によって動作が変更されることはありません。テストに失敗すると良いことかもしれません！失敗し続ける場合！

実際、マッドボールが十分にテストされることは非常にまれです。通常、コードは非常に密に結合されており、ほとんどのレガシーコードでは、テスト駆動型アプローチでは開発されておらず、ユニットテストでさえ開発されていません。

そのようなテストコードがまったくない場合は、最初に記述する必要があります。

戦略

はい、移行は隔離された状態を維持する必要があります。しかし同時に統合されました。ここではおかしく聞こえるかもしれませんが、自信がビジネスにどのように対応できるかを説明する他の言葉は見つかりません。この移行のためのスペースを確保するために、大きなモノリシックコードベースの開発をやめたい企業はまったくありませんが、ごくわずかです。おそらく何百人もの開発者がコードベースに継続的に貢献しているかもしれません（私たちのPOVから改ざん語を使用します）。自信を与えるために特定のスナップショットに取り組む必要がありますが、永遠に遅れをとらないようにするために、ここではgitの意味ではなく、リベースを維持する必要があります。

ここの実装戦略は、さまざまな経験を与えることができます。開発の一般的な方法は、コアと対話する必要がある場合に、新しい実装ブランチ（この場合は他のリポジトリに住んでいる）をラップ/適応（エンドポイントをオプションで再配置したスキームで公開）することです。このような戦略での移行とリファクタリングは、同時にVCS移行のPOCシナリオを提供し、後で段階的なアプローチを提供します。泥の玉を彫るようなものです。うん、人生はとても面白いものを提供します。

技術債務

経営管理分野は技術的負債を理解し、それを考慮に入れ始めました。いや、それを引っ掻いて、真実ではない。静的コード分析、コードレビュー、動作テストの結果、パフォーマンスの観点から測定値と品質データを収集し、素晴らしいレポートとすべてを生成することはますます一般的になっていますが...リファクタリングアプローチ。それのビジネス価値。「私たちはアジャイルプロセスに従っていますが、これにより機能が強化されることはありませんか？」。基本的に、そうすることで、彼らは技術的負債の存在を否定しています。これは、モノリスアーキテクチャからマイクロサービスアーキテクチャへの移行を開始するために必要な、一般的に不足しているステップと考えています。

再集合

結局のところ、複数の単一の製品を構築できる単一のリポジトリのようなビューを提供したい場合があります。何らかの理由、つまりcurr / next release、マルチブランド、顧客ビルド。この場合、Googleリポジトリなどのツールが役立ちます。自分で使ったことはありませんが、いつか必要になると思います。

統合テスト

マイクロサービスでは、統合テストは「独自のAPIをテストする」という異なるコンテキストを想定しています。機能またはパフォーマンスのテストのより高い層は存在する可能性がありますが、適切な統合テストなしでは意味がありますか？単体テストなしで統合テストを行うようなものです。もちろん違います。git bisectをgitする必要がある場合、それをマイクロサービスリポジトリブランチで実行し、それをmudballリポジトリで実行することを忘れるのはそのためです。

PS。これは下書きです、私の英語は下手で、いつか修正します