ホットフィックスを使用した分散アプリケーションのアセンブリのバージョン管理

Question

複数の物理層にコンポーネントを備えたアプリケーションを開発し、多くのアセンブリを共有するとともに、各層専用のアプリケーションを開発しています。

ホットフィックスをリリースするための典型的なバージョン管理戦略、またはアプリケーションのいくつかのコンポーネントのみを知りたいです。

問題追跡ソフトウェアには、製品全体のバージョン番号が含まれています。現在のバージョンが1.4.5で、ホットフィックスが必要な場合、ホットフィックスの問題は1.4.6に対してリリースされます。 1.4.6の修正の影響を受けるすべてのアセンブリは、バージョン1.4.6です。それらのファイルだけを配布した場合、バージョン1.4.5と1.4.6でいくつかのファイルが作成されます。

ソリューションとしては、アプリケーション全体を1.4.6として再構築およびリリースすることもできますが、これには複数のマシン上の複数のコンポーネントを再デプロイする必要があり、実際には変更されないコンポーネントの不必要なダウンタイムが発生します。

この問題に対して、人々はどのような戦略を立てていますか？一部のファイルが異なるバージョン番号を持つことを受け入れるだけの問題ですか？過去に、これが顧客（レベル1）サポートチームとの混乱を引き起こすことを発見しました。

Answer 1

あなたは興味深い質問を投げかけます。

これは、展開とバージョン管理の戦略を決定し、さまざまな要因（顧客の混乱など既に指摘したもの）のトレードオフを検討するために行う必要のあるポリシー決定です。

できることの1つは、個々の層のリリースとバージョン管理を切り離すことです。これにより、修正プログラムの展開オーバーヘッドを削減しながら、階層内で一貫したバージョン管理を行うことができます。また、共通のアセンブリを、独立したパッケージとバージョンに分解する必要もあります。

これはやり過ぎかもしれませんので、バージョン管理を理解しやすくすることもできます。たとえば、修正プログラムを示すためにバージョン番号の一部を予約できます。たとえば、1.4.5.0が公式リリースの場合、修正プログラムは1.4.5.1になり、これは1.4.5公式リリースの一部であると簡単に理解できます。

AssemblyInformationalVersion などの他のアセンブリバージョンを使用して、ユーザーのバージョン情報を保存することもできます。 （私のブログ投稿で、< code> AssemblyInformationalVersion および.NETのアセンブリバージョン管理）