分散アーキテクチャでは、なぜバージョン管理が難しいのですか？

Question

私はこの時間と時間をもう一度見ます。 UATのテストマネージャーは、新しいビルドを金曜日までにテストできる状態にしたいと考えている。事前テスト会議で、最初に質問されたのは、「どのバージョンをテストするのですか？」という質問です。 （これは公正な質問です）。部屋は静かになり、誰かが "すべてのアセンブリは独自のバージョンを持っています。右クリックしてプロパティを見てください..."と返されます。

テストマネージャの視点から見ると、これは役に立たない。彼らは、のすべてのバージョン/ラベル/タグが、彼らが何をしているのかを知らせるすべてのを求めています。彼らはこの情報を簡単に入手したい。

私はシステムの異なる領域のバージョンがデータストアに保存され、次にメインアプリケーションのaboutボックスに表示されるソリューションを見てきました。問題は、これを維持する必要があることです。

この問題を回避するにはどのような解決策がありますか？

EDIT。分散システムは、VB6、クラシックASP、VB.Net、C＃、Web Services（部門間でどのバージョンを使用していますか？）、SQL Server 2005などを網羅しています。

Answer 1

私はあなたとあなたのテストマネージャーが2つの異なることを話していると思います。アセンブリバージョンはアセンブリには最適ですが、テストマネージャは、より高いレベルのバージョン、つまり「システムバージョン」と言います。少なくともそれはあなたの記事の私の読書です。

あなたがこのような状況で行う必要があることは、さまざまなコンポーネントアセンブリをすべてシステムバージョンにマップすることです。 「システムのバージョン1.5は、Foo.Bar.dll v1.4.6とBaz.Qux.dll v2.6.7（など）で構成されています」という行に沿って何か言います。地獄では、分散システムでは、サービスごとに異なるバージョンが必要な場合があります。異なるバージョンの.dllファイルで構成することもできます。たとえば、「システムのバージョン1.5は、Foo.dll v1.9.3とBar.dll v1.6.9で構成されたFooサービスv1.3と、Barサービスv1.9で構成されています。 Baz.dll v1.8.2とQux.dll v1.5.2と（など）で構成されています。

このようなことは、通常、組織のソフトウェアアーキテクトおよび/またはビルドマネージャの仕事です。

この問題に対処するために使用するツールは、使用する言語とは無関係です。私の個人的なお気に入りは現在Jiraで、バグ追跡に加えて、優れた製品バージョン管理とロードマップサポートがあります。

Answer 2

いくつかの点を説明するthis page一貫したバージョン管理をビルドプロセスに統合します。

Answer 3

内部参照以外はビルドベースのバージョン番号を使用しません。 UATのマネージャーが質問すると、あなたは「金曜日の*」と言います。

次に、ソースコントロールで確実にラベリングが確実に行われるようにするしかありません。

*ここでは、適切な日付スタンプ/ラベル

Answer 4

我々は、.NETとSubversionを使用を挿入します。私たちのアプリケーションアセンブリはすべて、手動で更新されたメジャーおよびマイナーリビジョン番号とSubversionリビジョン番号（<major>.<minor>.<revision>）から派生したバージョン番号を共有しています。共有AssemblyVersionInfo.vbファイルでこのバージョン番号を更新するプレビルドタスクがあります。そして、テスターがバージョン番号を尋ねるときには、完全な3つの部分の番号か、ただのSubversionのリビジョンを与えることができます。消費するライブラリは変更されていないか、変更はテスターに​​関係ありません。

Answer 5

問題の原因になるものは数多くあります。

分散アーキテクチャのメリットの1つは、サービスを作成してインターフェイスを何らかの形で公開することで、再利用の可能性が大きくなるということです。つまり、クライアントアプリケーションのリリースは、基盤となるサービスのリリースと必ずしも密接に同期するとは限りません。したがって、1年間使用していた同じ古い信頼性の高いサービスを使用する新しいバージョンのビジネスアプリケーションがリリースされる可能性があります。この場合、単一のリリースタグをどのように適用する必要がありますか？

しかし、これは公正な質問ですが、意味のある重要な答えが必要なものです。