4

Team Foundation Server のソース管理構造を読んだ後、いくつかの質問が頭に浮かび、誰かがコメントできるかどうか疑問に思っています。

私が取り組んでいるプロジェクトを構成するいくつかのコンポーネントがあります。スマートクライアント、Web サービス、スマートクライアントが使用する Web サービスのプロキシ、デーモン、およびスマートクライアントと Web サービスの両方で使用される共通ユーティリティ ライブラリがあります。各コンポーネントは、同じ作業プロジェクトに関連付けられています。

各コンポーネントが独立するようにソース ツリーを構成しました。つまり、各コンポーネント (スマートクライアント、Web サービス、デーモン、プロキシ、共通ユーティリティ) には、それぞれをリリースできるように、独自のトランクと独自のソリューション ファイルがあります。コンポーネントを独立して。プロキシと共通ユーティリティを使用するスマートクライアントの場合など、他のコンポーネントによって使用されるコンポーネントについては、他のサードパーティ ライブラリ (プロジェクトの代わりに参照されるバイナリ) と同様に処理されるリリースを作成しました。これがベストプラクティスであることを誰かが確認できますか?

私は tfs build を使用してコンポーネントのリリースをビルドしてきましたが、すべての tfs ビルドが存在するビルド出力ディレクトリ以外の場所にある場合、リリースをどこに置くべきか疑問に思っています。おそらく、それら (スマートクライアントで使用されるプロキシ リリース アセンブリなど) を他のサード パーティ ライブラリと共に TFS にチェックインし、リリース アセンブリを使用する場所に分岐する必要があります (たとえば、プロキシ リリース DLL をスマートクライアント lib ディレクトリに分岐します)。 ?

4

2 に答える 2

3

私たちが行ったことは、各主要な共有プロジェクトに対応するサブフォルダーを含むTFSサーバー上にパブリック\common共有を作成することです。例えば： 

\\一般  
    \ sharedproject1
        \ v1.0.0
        ..。
        \ vN.0.0
    ..。
    \ sharedprojectN

非共有プロジェクトのそれぞれは、\ common \ sharedprojectN \ vM.mnの特定の共有アセンブリを参照します

まず、必要に応じて共有プロジェクトの自動ビルドを実行します。
次に、ビルド品質を特定の値に変更すると（「参照の準備ができました」など）、ビルドの出力をこれらの共有バージョンの1つに自動的にコピーする必要があることを示します。

次に、これらの共有プロジェクトの出力を使用して、プロジェクトの自動ビルドを実行できます。
他のビルド品質ステータス（「システム統合の準備ができました」など）を使用して、メインアプリケーションのビルドが特定の環境（テストなど）に展開する準備ができていることを示します。これにより、プロジェクト出力がパブリック\release共有
の特定のリリースフォルダーにパッケージ化されます。

最後に、自動展開ツールを使用して、特定のリリースを特定のターゲット環境の適切なサーバーにインストールします。

于 2009-07-30T13:31:23.733 に答える
2

したがって、基本的には、「依存関係のレプリケーション」として一般に知られているものを指しています。チーム ビルドを利用して、依存関係を複製します。ビルドを連鎖させる「Dependency Replicator」というツールがあります。

したがって、たとえば、ユーティリティ クラスはあまり変わらないかもしれません。A) サーバー上でビルドする B) すべての依存プロジェクトも同様にビルドする。

依存関係レプリケーターを使用すると、アセンブリが相互に依存する方法と、依存関係が更新されたときに実行する「ビルド」を (XML で) 指定できます。

于 2009-01-22T10:25:37.437 に答える