4

複数の物理層のコンポーネントを使用してアプリケーションを開発しており、多くのアセンブリを共有し、各層専用のものを持っています。

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

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

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

この問題に対して人々はどのような戦略を立てましたか? 一部のファイルのバージョン番号が異なることを受け入れるだけの問題ですか? 過去に、これが顧客 (レベル 1) サポート チームとの混乱の原因になっていることがわかりました。

4

1 に答える 1

2

あなたは興味深い質問をします。

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

実行できることの 1 つは、個々の層のリリースとバージョン管理を切り離すことです。これにより、ホットフィックスの展開のオーバーヘッドを削減しながら、層内で一貫したバージョン管理を行うことができます。また、共通のアセンブリを個別のパッケージとバージョンに分解する必要もあります。

これはやり過ぎかもしれないので、別の方法としては、バージョン管理を把握しやすくすることです。たとえば、ホットフィックスを示すためにバージョン番号の一部を予約できます。たとえば、1.4.5.0 が公式リリースの場合、ホットフィックスは 1.4.5.1 となり、これは 1.4.5 公式リリースの一部であることが容易に理解できます。

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

于 2009-04-30T19:24:36.733 に答える