私は継続的インテグレーションの概念実証を行っており、開発チームが自動ビルドと自動デプロイによって人的エラーを削減できるかどうかを確認しています。私はすでにプロセスをかなり進めてきましたが、コード変更のない依存関係の再構築を回避するためにインクリメンタル ビルドを構成する方法についていくつか質問があります。さらに、配置ツールで、コード変更の結果として再構築されたアセンブリのみを識別して配置できるようにしたいと考えています。
ソース管理には TFS、開発には Visual Studio、継続的インテグレーション ビルドには Team Foundation Build などの Microsoft 製品を既に使用しています。現在、Team Foundation Build とうまく統合されているように見えるので、展開用に InRelease に傾いています。
しかし、まず、これが現在のセットアップです...
200 以上の C# ソリューション ファイルがあり、それぞれに 1 つ以上のプロジェクトが含まれています。これらのプロジェクトをより少ないソリューションに結合することは、環境では実際的ではありません。つまり、設計によるものです。ソリューション内のプロジェクトは、プロジェクト参照を使用して依存関係を解決し、他のソリューション内のプロジェクトへのファイル参照を解決します。私の知る限り、これは大量のプロジェクトを扱う場合に Microsoft が推奨するアプローチです。
「機能ごとのブランチ」戦略を使用します。たとえば、完了時に安定したメイン ブランチにマージされる並行機能ブランチでの分離された開発です。リリースの時期になると、リリースはメインから分岐され、ホットフィックスと展開のために分離されます。フィーチャー ブランチとメイン ブランチには、コード チェックインによってトリガーされる CI ビルドがあります。リリースは、ほとんどの場合、選択したリリース ブランチに対して InRelease から手動で実行するのが好きです。リリースは、統合/テスト、UAT を含むさまざまな環境を通じて展開され、最終的にすべてのクライアントに展開されます。分岐戦略の詳細はまだ具体化中ですが、それはまた別の機会に。
解決すべき現在の問題:
1.コードの変更がない依存関係の再構築を避ける...
新しい機能やパッチをクライアントに展開するときは、最小限のファイルをプッシュする必要があります。私たちの会社には非常に大規模な顧客ベース (数千の顧客) がいて、インターネット接続が遅い場合があるため、すべてのアセンブリ (200 以上) をすべての顧客に完全に展開することは選択肢ではありません。コードの変更が行われていない場合でも、変更されたプロジェクトのみを正しく再構築するだけでなく、すべての依存プロジェクトも再構築する増分ビルドを設定することで、問題を部分的に解決しました。これにより、変更されたアセンブリと依存関係の両方が新しいタイムスタンプを持つことになります。タイムスタンプの変更を使用して展開するアセンブリを特定すると、機能的に変更されていないアセンブリが展開されることになります。
例えば：
ソリューション B にはプロジェクト B というプロジェクトがあります ソリューション A にはプロジェクト A というプロジェクトがあります
プロジェクト B -> プロジェクト A (プロジェクト A はプロジェクト B にファイル依存関係があります)
プロジェクト A で破壊的でない変更が行われた場合、たとえばメソッドの内部に変更が加えられた場合、期待される結果は次のとおりです。A のみがビルドされ、展開の候補になります。プロジェクト Aで重大な変更が行われると、プロジェクト B が壊れます。期待される結果は次のとおりです。A と B の両方がビルドされ、展開の候補になります。現在、MSBuild は関係なくすべての依存関係を再構築しますが、これは私たちが望んでいるものではありません。
2. 展開する必要があるアセンブリを自動的に識別します...
問題の部分的な解決策があります。ビルドが実行されると、ビルド プロセス テンプレートは、特定の順序でビルドするソリューションのリストを含む MSBuild スクリプトを実行するように構成されます。この操作は、ビルド エージェントのワークスペースで実行されます。新しいビルドが実行されるたびに、ビルド プロセス テンプレートは、次の形式で一意のドロップ フォルダーを作成します。バイナリをビルド エージェント ワークスペースからドロップ フォルダーにコピーします。これは、標準のビルド プロセス テンプレートによって処理されるすぐに使える機能です。ビルドはビルド エージェント ワークスペースをクリアしないように構成されているため、最初に実行するとソリューション内のすべてのプロジェクトがビルドされますが、その後のビルドでは、コードが変更されているか、他のプロジェクトに依存しているプロジェクト (インクリメンタル ビルド?) のみがビルドされます。したがって、変更されていないアセンブリには元のタイム スタンプが付けられ、変更されたアセンブリには新しいタイム スタンプが付けられます。ドロップ フォルダー間のフォルダー比較を実行し、結果を txt ファイルに出力できるツールがあります。これにより、最後の展開以降に追加/変更/削除されたバイナリを特定できます。また、実際のアーティファクトのリストを、開発者が定義した予期されるアーティファクトのマニフェストと比較できるという追加の利点も得られます。これにより、指定されておらず、単体テスト済みであることが証明されていないアセンブリがデプロイされないようになります。
問題は、ドロップ フォルダー内のすべてのファイルではなく、上記の例のように必要なファイルのみを展開するために、InRelease をどのように活用できるかということです。