到目前为止,我们的团队与VSS合作,我们正处于流程中,转向TFS2010和VS2010。 我们的大部分代码都是C ++,我们使用了许多第三方库,如Boost,OpenCV,OpenSSL等。 根据我读到的最佳实践,我正在考虑在我们的多个解决方案和项目中处理第三方标题和库的一些选项。
我为所有第三方库创建一个独立的TFS项目,并为每个库和每个版本存储源/包含/输出。例如:
Dependencies\
-> Boost\
->boost_ver1\*
->boost_ver2\*
-> OpenSSL\
->openssl-ver1\*
->openssl-ver2\**
我的TFS源代码树如下所示:
$\
-> Dependencies\
-> TeamProject1\
-> TeamProject2\
-> TeamProject3\
我们的TeamProject可能在文件夹树中的不同级别包含多个解决方案。
我为每个团队项目准备一个dependencies.props
文件,以便将给定团队项目的所有项目导入。该.props文件将相关的第三方软件包添加到$(IncludePath)
和$(LibraryPath)
。为了做到这一点,我假设Dependencies项目映射到每个用户每台机器的全局环境变量定义的文件夹。
关于这种方法,我有几个问题:
我不知道如何使它在构建代理上工作,因为我无法在构建定义的工作区映射选项卡中指定环境变量。据我所知,每个版本都会更改BuildDirectory var和SourceDir var。
在开始构建任何TeamProject解决方案之前,如何确保获得最新的相关第三方依赖项。
这是一个“好”的方法吗?
答案 0 :(得分:0)
1:如果您希望构建确定构建定义本身需要哪些依赖项集合,则可以使用msbuild参数或powershell参数将参数传递到流程模板。只要通用依赖项和该文件包含在工作区中,您也可以让逻辑从props文件中提取信息。
2:只要包含依赖关系的源控制路径在构建定义中映射,它就会在构建解决方案之前同步源控件中的最新版本,并在构建解决方案之前使用它们。
3:不是特别针对你的情况。我建议不要使用通用依赖项区域,因为如果您执行类似gated构建的操作,您将在您的gated check-in窗口中弹出所有3个构建。此外,对一种解决方案的改变可以在不经意间切实地影响所有三种解决方案。你考虑过使用nuget吗?这可能是保持3个解决方案分离的最佳实践,也可能具有可供部分或全部使用的依赖关系。例如,大多数编码工作的大多数常见依赖项都有可下载的nuget包,这些包将在构建期间下载,甚至不必检查它们。