TFS生成分支的服务器生成?

确认:

• $(solutiontobuild)在引用product.sln时使用相对路径
• $/newfeature/../tfsbuild.proj和$/newfeature/product.sln之间的相对路径与主分支中的路径相同。

编辑/

不过,请注意, 不 重要的是,$/main和$/branches/功能在树层次结构中处于同一级别。构建服务器上的本地路径也不重要。*重要的是每个分支下面的内容。如果 内容 是内部一致的,那么所有现有的构建脚本都应该在不进行修改的情况下工作。

有关我如何将所有事情联系在一起的具体示例,请参阅我过去的答案,例如:

• Modular TeamBuilds
• SDLC Mangement for TFS Build Scripts
• Where to put my database project in TFS?
• How do you share external dependencies between Visual Studio solutions?

我的方法不是唯一的方法,但我可以证明它比我多年来遇到的所有其他变体都更有效。)

*坦率地说,试图对团队构建进行微观管理可能会比对msbuild脚本进行拟议的重组更加痛苦。为了保证可靠性,你必须 tfsbuildservice.exe.config customizations 在某个地方的版本控制下……如果您拥有1个构建服务器(或将来可能拥有),那么您必须考虑更改部署策略……您最终需要一个元SCM流程来管理您的SCM流程!

在TFS2010中,当从一个分支运行构建时,我也遇到了这个问题。TFS报告说,“没有$/main/product.sln的工作文件夹映射”,解决方案是按如下方式编辑生成定义(我使用的是“默认模板”生成过程模板“我没有用自定义模板尝试过这一点):

1. 转到生成定义的流程部分/选项卡。
2. 展开 1。要求的 寻找 要生成的项目 . 确保此条目指向您正在构建的分支内的解决方案文件。
3. 展开 2。基本的 寻找 自动化测试 . 将其指向正在构建的分支中的正确测试设置文件。

好的,结果是-我找到了一个解决办法。

由于我们遗留的构建过程(构建、复制、混淆、构建自定义安装程序、复制到放置文件夹),我无法轻松地放置分支 沿着 主要分支机构。它需要 代替 它。

因此,如果我有main和newfeature,我希望取消映射main并将newfeature映射到它的位置(即,在构建服务器上使用“c:\main”,只需更改出现在那里的源代码)。

解1 (最简单、明显和合乎逻辑的解决方案)是使用这些映射:

• $/newfeature->C:\main

预期结果:NewFeature代码结构简单地替换了main,而构建服务器不知道它在不同的分支上。

实际结果:失败,出现“You have not mapped$/main even t you're not using it”(即使您没有使用它也没有映射$/main)错误。

解2 是这样做的:

• $/main->c:\ignorethisfolder
• $/newfeature->C:\main

这是有效的(它抑制了警告,从而允许生成继续进行msbuild,而不知道它正在分支中生成)。但是,它是丑陋的,构建不必要地获取所有主要分支源代码。

解3 (未经测试,除非我知道它比2好得多,否则无法尝试)是:

• 将所有源代码(从$/main、$/branches/feature)移动到$/branches/main和$/branches/feature以获得一致的层次结构深度,并重写msbuild脚本以使用这些新路径。

• 希望我可以只映射我需要的分支,然后编辑tfsbuild.proj将其重定向到该分支中的build。

  (编辑:是的,这很管用。我们现在已经重新组织了整个代码结构,以便在单个团队项目中,所有的(所有分支)都在一个共同的根下,并且分支/构建不再是一个问题——我们现在很容易做任何需要做的事情。技巧是将根文件夹插入到层次结构中,以便可以在任意级别进行分支。我在构建脚本中添加了一个小的调整,这样我们就可以将分支作为参数传递给msbuild,所以现在很容易构建任何变量。我们不想处理的任何分支都可以被隐藏起来,构建服务器仍然很高兴。)

总结 所有这些解决方案(使用技术术语)都很糟糕。您必须重新映射工作区(在本例中,这并不简单:需要9个映射条目,因此这是一个容易出错且繁琐的操作),编辑tfsbuild.proj,删除所有源代码,并使用/p:forceget=true运行生成以在分支之间切换生成。所以切换分支大约需要一个小时。难以置信-最多需要几分钟!

我意识到我们的项目离理想的设置还很远,但我不能相信在tfs中进行分支会如此困难(在sourcesafe、accurev和performce中这是小菜一碟,那么为什么在tfs中如此痛苦呢?).

其他人如何组织他们的TFS分支机构?如何在分支之间切换开发人员?如何在分支之间切换服务器构建?真的要这么痛苦吗?

编辑生成定义时,有两个地方需要更改。

1. 源设置-指向新项目位置
2. 处理(有时需要一段时间加载,所以要耐心)在“必需”下,将“要构建的项”位置更改为新的解决方案。

希望这有帮助。

新更新:

正如在另一个答案中所报告的,我发现了一个短期功能分支的变通方法,但它确实没有很好地工作。从那以后,我又回到了这个问题上,完整的解决方案非常简单:

在tfsbuild.proj中,路径基于$(BuildProjectFolderPath)。此路径解析为 服务器端 (源代码管理路径)如$/main-不是本地路径(d:\serverbuildfolder\main)。

不幸的是,由于历史原因,我们的源代码被拆分为多个团队项目,这意味着一个“分支”被拆分为源代码管理中的多个分支文件夹(即$/main/code和$/libraries/code)。无法创建包含$/main和$/libraries的分支)。因此,我们必须使用工作区映射将这些来自源代码控制的不同片段重新组合到一个一致的层次结构中。

这意味着Richard在-从tfsbuild.proj文件到.sln文件的相对路径不正确,因为msbuild/tfs假定.sln位于同一团队项目和源代码管理层次结构中(因此查找的是$/main/libraries.sln而不是$/libraries/libraries.sln)。

解决方案很简单:我用文件的本地路径(例如d:\serverbuildfolder\main)替换了$(buildprojectfolderpath),以便在“本地空间”(应用映射后)中解析相对引用,而msbuild现在运行得很好。

故事的寓意: 1)如果您希望在这些代码库之间有任何类型的引用,则不要使用多个团队项目。不要被愚弄,以为一个新的团队项目将在应用程序/库之间提供某种无痛的逻辑区别。事实证明,额外的项目只是一场管理噩梦——为绝对零收益而带来的大量额外问题。(这是引擎盖下的一个大共享堆,因此所有工作项和源代码管理文件夹在所有项目中仍然可见!!)但它添加了一些砖墙,使得项目间的链接非常有问题)

2)始终在团队项目源代码管理中创建一个根级别的文件夹,然后将其他所有内容放在该文件夹下。例如,对于项目“$/main”,创建“$/main/root”,然后将源层次结构中的所有内容都放到根中。

通过遵循这些规则,您将来可以对单个“根”文件夹进行分支,然后只需要一个分支和一个额外的工作区映射。这将帮助你避免过早秃顶。

(在我的辩护中,我会这样做,从一开始-我正在处理一个遗留设置。为了保护传统的设置,它在纸面上听起来不错,但并不是微软支持的方法!)

我得到了这个错误,我所能理解的就是这个定义被破坏了。我只是重新设计了流程工具(重新添加了我试图构建的解决方案),重新映射了工作区,然后它又开始工作了。Hth.