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

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.4.5.0が公式リリースの場合、修正プログラムは1.4.5.1となり、これは1.4.5公式リリースの一部であると容易に理解できます。

AssemblyInformationalVersionなどの他のアセンブリバージョンを使用して、ユーザーのバージョン情報を格納することもできます。 （AssemblyInformationalVersionと.NETのアセンブリバージョン管理の詳細については、my blog postを参照してください。）