2

到目前为止，我们的团队一直在使用 VSS，我们正处于迁移到 TFS2010 和 VS2010 的过程中。我们的大部分代码是 C++，我们使用了很多 3rd 方库，例如 Boost、OpenCV、OpenSSL 等。根据我阅读的最佳实践，我正在考虑在我们的多个解决方案和项目中处理 3rd 方标头和库的一些选项。

  1. 我为所有 3rd 方库创建了一个独立的 TFS 项目，并在每个库和每个版本中存储源/包含/输出。例如：

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

  2. 我的 TFS 源代码树如下所示：

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

  3. 我们的 TeamProject(s) 可能包含文件夹树中不同级别的多个解决方案。

  4. 我为dependencies.props每个团队项目准备一个文件，给定团队项目的所有项目都导入到该文件中。该 .props 文件将相关的 3rd 方包添加到$(IncludePath)和$(LibraryPath). 为了做到这一点，我假设 Dependencies 项目被映射到由每个用户每台机器的全局环境变量定义的文件夹。

我对这种方法有几个问题：

  1. 我不知道如何使它在构建代理上工作，因为我无法在构建定义的工作区映射选项卡中指定环境变量。我了解每次构建都会更改 BuildDirectory var 和 SourceDir var。

  2. 如何确保在开始构建任何 TeamProject 解决方案之前获得最新的相关第三方依赖项。

  3. 这是一个“好”的方法吗？

4

1 回答 1

0

1：如果您希望您的构建确定构建定义本身所需的一组依赖项，您可以使用 msbuild 参数或 powershell 参数将参数传递给您的流程模板。只要通用依赖项和该文件包含在您的工作区中，您还可以让您的逻辑从您的 props 文件中提取信息。

2：只要包含依赖项的源代码控制路径映射到构建定义中，它就会在构建您的解决方案之前从源代码控制同步最新版本，并在构建解决方案之前拥有它们。

3：不是特别适合你的情况。我建议不要使用通用依赖项区域，因为如果您执行门控构建之类的操作，您将在门控签入窗口中弹出所有 3 个构建。此外，对一种解决方案的更改可能会无意中影响所有三种解决方案。您是否考虑过使用nuget？这可能是使您的 3 个解决方案分开并且还具有可供部分或全部使用的依赖项的最佳实践。例如，大多数编码工作的最常见依赖项都有可下载的 nuget 包，这些包将在构建期间下载，甚至无需签入。

于 2015-02-09T18:43:35.020 回答