ビルドパイプライン、未リリースパッケージへの依存
私のチームは現在、ソリューション構造にいくつかの変更を加えています。変更前は、基本的に約40の異なるプロジェクトを持つ単一のソリューションファイルがありました。これらのプロジェクトのほとんどは、いくつかのアプリケーションによって使用されるライブラリです。
ロードとビルド時間を改善するために、ソリューションをいくつかの小さなソリューションに分割することにしました。最大のライブラリの2つから始めました。それらをコアとDALと呼びましょう。どちらも、単一のプロジェクトで独自のソリューションを得ました。
両方のプロジェクトに2つのビルドパイプラインを作成しました。 1つはプルリクエスト用、もう1つはメインブランチへのマージ後にNuGetパッケージをビルドするためのものです。各PRには2つのレビューがあり、ビルド/テストの結果がパイプラインで成功するというポリシーがあります。
次に、DAL（v1.0.0）に架空のバグがあるとします。
以前は、ライブラリのバグを修正し、一部のアプリケーションをローカルで実行し（更新されたDLLを呼び出します）、動作する場合は変更をコミットし、PRを開始します。これにより、PRパイプラインが開始され、ほぼ完了します。
しかし、新しいシナリオでは、変更をテストするために、開発者はローカルのNuGetパッケージを公開する必要があります。たとえば、1.0.1-preとします。次に、1つ以上のアプリケーションでパッケージを更新し、すべてが問題なければ、ローカル1.0.1パッケージを公開し、消費するアプリケーションを更新して、バグ修正のための単一のPRを作成しますandバージョンの増加消費アプリケーションで。
しかし、ここにキッカーがあります。新しいパッケージはまだフィードに公開されていないため、これらの消費アプリケーションのPRパイプラインは失敗します。パッケージを公開するには、PRを完了する必要がありますが、ライブラリへの変更はアプリのバージョンが上がるのと同じPRにあるため、これは不可能です。
この問題のために、すべての開発者に、パッケージへの変更を他の変更と同じPRに含めないように指示しているところです（たとえそれらが非常に関連しているとしても）。しかし、最後の手段として、より良いアプローチ。
PRは1つのプロジェクトのみに対応する必要があります
パッケージの更新は、パッケージのコンシューマーの更新とは別にする必要があります。
DALにバグがある場合は、DALで修正する必要があります。PRがビルドとそのバージョンバンプをトリガーし、新しいパッケージが表示されます。
これで、使用するアプリケーションはパッケージをプルし、関連する更新を実行できます。これは、そのバージョンと後続のパッケージをバンプするPRで渡されます。
その理由は、使用中のアプリケーションがまだ新しいパッケージに移行できない可能性があるためです。これは、規制上の理由、またはコンシューマでの追加のコード変更が原因である可能性があります。
個別のプロジェクト<->個別のリポジトリ
DALが別のプロジェクトであるかどうかを決定します。
そうでない場合は、パッケージを破棄し、現在のチェックインでビルドされたライブラリを使用します。それ以外の場合、アプリケーションはその履歴の末尾を追跡し、以前のコミットの結果に依存します。
もしそうなら、それを新しいリポジトリにリホームし、実際にそれ自身のパッケージを持つことによって暗黙に示される独立性を与えます。
品質ゲートとレッドフラグ
もう1つの問題は、品質ゲートです。 DALパッケージの品質ゲートは使用するアプリで機能するのようです。品質ゲートに関して言えば、間違いなくそれが最終目標ですが、テストに対応するために行われた作業が、新しいパッケージを組み込む作業とほとんど同じになるという状況に陥ります。
これは私の心にいくつかの赤信号を発生させます：
- DALのユニット/モジュール/セマンティックテストは、DALのコードと一緒に自己完結型ではなく、リポジトリ全体に広がっています。
- バージョン番号を上げる以外の消費アプリケーションへの変更は、以下を意味します：
- 機能はまだ使用されているときに削除されました。
- 機能が大幅に変更されました。これは、機能を削除し、同様のシグネチャで新しい何かを作成したのと同じです。陰湿なバグの原因。
- 消費するアプリケーションは常に不正確であり、消費するアプリケーションはテストとして使用されているため、テストは常に間違っていたため、最初に修正する必要があります（実際には、消費するアプリケーションを最初に修正する必要があります。バージョン）。
- 使用するアプリケーションに変更を加えると、以前に作成および承認されたDALパッケージが無効になる可能性があります。
品質ゲートと自動化目標の明確化
品質ゲートを明確に定義し、依存パッケージの更新を潜在的に自動化します。
まず、DALとやり取りする使用中のアプリケーション内のすべての場所を検索し、それらのやり取りをモジュール/ユニットテストに絞り込みます。これを、DALパッケージを構築するための品質ゲートにします（レビューなどの人間の品質測定と共に）。
DALパッケージが作成されたら、2番目の品質ゲートは、消費するアプリケーションコードをチェックアウトすることです。依存関係を更新してテストし、プルリクエストを自動的に生成します。アーキテクチャで許可されている場合は、消費アプリケーションへの各PRが受け入れられた後もチェックされるため、消費アプリケーションが「修正」された場合、自動的に優れたパッケージが提案されます。
開発者は、（ほとんどの）バグ修正と拡張された動作を含む、互換性のない変更についてPRを1回実行する必要があります。これらは、パッチおよびマイナーサーバーバンプに対応します。 DALを更新するだけで、ダウンストリームコンシューマに更新が提案されます。
セマンティクスがまだ定義/再定義されているため、重大な変更は必然的に主にさらに複雑になります。ただし、これは例外ではなく、ルールです。これらの変更は、パッケージが使用中のアプリケーションに自動的に適用されないように、メジャーバージョンのバンプの下で行われる必要があります。
開発者がパッケージを更新するのを支援するために、メイン/それらのフォークから各ダウンストリームシステムを構築/テストする手段を提供します。現在公開されているパッケージに対するビルド/テスト結果も提供する場合の追加ポイント。これにより、開発者はパッケージが重大な変更であるかどうかを知ることができます。また、PRが新しいパッケージに依存しているかどうか、および特定のプロジェクトのPRをいつプッシュできるかを決定することもできます。
大きなプロジェクトを小さなプロジェクトに分割するときは、そのプロジェクトがどのようにテストされるかについて考える必要があります。実際には、大きなプロジェクトを別々の開発/ビルドプロジェクトに分離することにより、それらのプロジェクトは、使用される場所から独立している必要があると想定する必要があります。また、ライフサイクルが上流の依存関係から完全に分離していること。
基本的に、COREとDALへの分割は単に正しくありません。設計図に戻り、ソリューションを再構築して、上流の依存関係を必要とせずに各プロジェクトへの変更をテストできるようにします。