2

これまで私たちのチームは VSS を使用していましたが、TFS2010 と VS2010 に移行するプロセスの途中です。私たちのコードのほとんどは C++ であり、Boost、OpenCV、OpenSSL などの多くのサードパーティ ライブラリを使用しています。私が読んだベスト プラクティスに基づいて、複数のソリューションとプロジェクトでサード パーティのヘッダーとライブラリを処理するためのいくつかのオプションを検討しています。

  1. すべてのサード パーティ ライブラリ用のスタンドアロン TFS プロジェクトを作成し、ライブラリごとおよびバージョンごとにソース/インクルード/出力を保存します。例えば：

    Dependencies\
  -> Boost\
         ->boost_ver1\*
         ->boost_ver2\*
  -> OpenSSL\
         ->openssl-ver1\*
         ->openssl-ver2\**

  2. 私の TFS ソース ツリーは次のようになります。

    $\
    -> Dependencies\
    -> TeamProject1\
    -> TeamProject2\
    -> TeamProject3\

  3. チームプロジェクトには、フォルダー ツリーのさまざまなレベルに複数のソリューションが含まれている場合があります。

  4. dependencies.props特定のチーム プロジェクトのすべてのプロジェクトがインポートされるチーム プロジェクトごとにファイルを準備します。その .props ファイルは、関連するサードパーティ パッケージを$(IncludePath)およびに追加します$(LibraryPath)。これを行うために、Dependencies プロジェクトは、ユーザーごとのマシンごとのグローバル環境変数によって定義されたフォルダーにマップされていると想定しています。

このアプローチに関していくつか質問があります。

  1. ビルド定義のワークスペース マッピング タブで環境変数を指定できないため、ビルド エージェントで動作させる方法がわかりません。BuildDirectory var と SourceDir var がビルドごとに変更されることを理解しています。

  2. TeamProject ソリューションの構築を開始する前に、最新の関連するサードパーティの依存関係を取得する方法。

  3. これはまったく「良い」アプローチですか？

4

1 に答える 1

0

1:ビルド定義自体から必要な依存関係のセットなどをビルドで決定する場合は、msbuild パラメーターまたは powershell パラメーターを使用してプロセス テンプレートにパラメーターを渡すことができます。また、一般的な依存関係とそのファイルがワークスペースに含まれている限り、ロジックで props ファイルから情報を取得することもできます。

2: 依存関係を含むソース管理パスがビルド定義にマップされている限り、ソリューションをビルドする前にソース管理から最新バージョンが同期され、ソリューションがビルドされる前にそれらが保持されます。

3：特にあなたの場合ではありません。ゲート ビルドなどを行うと、ゲート チェックイン ウィンドウに 3 つのビルドすべてがポップアップ表示されるため、一般的な依存関係領域を使用しないことをお勧めします。さらに、1 つのソリューションを変更すると、意図せずに 3 つすべてに影響を与える可能性があります。ナゲットの使用を検討しましたか？これはおそらく、3 つのソリューションを分離し、それらの一部またはすべてで使用できる依存関係を維持するためのベスト プラクティスです。たとえば、ほとんどのコーディング作業の最も一般的な依存関係には、ビルド中にチェックインしなくてもダウンロードできるダウンロード可能な nuget パッケージがあります。

于 2015-02-09T18:43:35.020 に答える