ホットフィックスを使用した分散アプリケーションのアセンブリのバージョン管理
-
03-07-2019 - |
質問
複数の物理層にコンポーネントを備えたアプリケーションを開発し、多くのアセンブリを共有するとともに、各層専用のアプリケーションを開発しています。
ホットフィックスをリリースするための典型的なバージョン管理戦略、またはアプリケーションのいくつかのコンポーネントのみを知りたいです。
問題追跡ソフトウェアには、製品全体のバージョン番号が含まれています。現在のバージョンが1.4.5で、ホットフィックスが必要な場合、ホットフィックスの問題は1.4.6に対してリリースされます。 1.4.6の修正の影響を受けるすべてのアセンブリは、バージョン1.4.6です。それらのファイルだけを配布した場合、バージョン1.4.5と1.4.6でいくつかのファイルが作成されます。
ソリューションとしては、アプリケーション全体を1.4.6として再構築およびリリースすることもできますが、これには複数のマシン上の複数のコンポーネントを再デプロイする必要があり、実際には変更されないコンポーネントの不必要なダウンタイムが発生します。
この問題に対して、人々はどのような戦略を立てていますか?一部のファイルが異なるバージョン番号を持つことを受け入れるだけの問題ですか?過去に、これが顧客(レベル1)サポートチームとの混乱を引き起こすことを発見しました。
解決
あなたは興味深い質問を投げかけます。
これは、展開とバージョン管理の戦略を決定し、さまざまな要因(顧客の混乱など既に指摘したもの)のトレードオフを検討するために行う必要のあるポリシー決定です。
できることの1つは、個々の層のリリースとバージョン管理を切り離すことです。これにより、修正プログラムの展開オーバーヘッドを削減しながら、階層内で一貫したバージョン管理を行うことができます。また、共通のアセンブリを、独立したパッケージとバージョンに分解する必要もあります。
これはやり過ぎかもしれませんので、バージョン管理を理解しやすくすることもできます。たとえば、修正プログラムを示すためにバージョン番号の一部を予約できます。たとえば、1.4.5.0が公式リリースの場合、修正プログラムは1.4.5.1になり、これは1.4.5公式リリースの一部であると簡単に理解できます。
AssemblyInformationalVersion
などの他のアセンブリバージョンを使用して、ユーザーのバージョン情報を保存することもできます。 (私のブログ投稿で、< code> AssemblyInformationalVersion および.NETのアセンブリバージョン管理)