分支的 TFS 构建服务器构建？

Question

我们有一个 TFS 2008 项目，它有两个分支（“Main”和“NewFeature”）。 每个都是源代码的完整、独立的“副本”（变体）。

通过更改工作区映射，我们可以将任一变体映射到我们的本地 PC 上，并且可以毫无问题地使用这两个分支。

但是，如果我设置映射以将我们的构建服务器切换到 NewFeature 分支（就构建服务器而言，它应该简单地交换 NewFeature 源代码而不更改任何其他内容）我会收到错误：

There is no working folder mapping for $/Main/Product.sln

即当它从 NewFeature 分支构建时，仍然在 Main 分支中查找某些内容，即使源代码中的任何地方都没有对该分支的引用。它似乎正在缓存一些对 Main 的引用？！

我已经完成了一个完全干净的构建（从服务器中删除构建文件夹并使用 /p:ForceGet=true 运行构建以确保映射已刷新到服务器，并且服务器上没有文件可能会缓存工作区绑定），但这没有帮助。

有什么建议吗？

Answer 1

验证：

• $(SolutionToBuild) 在引用 Product.sln 时使用相对路径
• $/NewFeature/.../TFSBuild.proj 和 $/NewFeature/Product.sln 之间的相对路径与 Main 分支中的相对路径相同。

/编辑/

但请注意，$/Main 和 $/Branches/Feature 在树层次结构中位于同一级别并不重要。构建服务器上的本地路径也不重要。*重要的是每个分支下面的内容。如果 contents 是内部一致的，那么您所有现有的构建脚本都应该可以在不修改的情况下工作。

有关我喜欢如何将所有内容联系在一起的具体示例，请参阅我过去的答案，例如：

• 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?

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

*坦率地说，尝试对 Team Build 进行微观管理可能比建议对 MSBuild 脚本进行重组要痛苦得多。为了可靠性，您必须将 tfsbuildservice.exe.config customizations 置于版本控制之下...如果您拥有 >1 个构建服务器（或将来可能），那么您必须考虑更改部署策略...您最终需要一个元用于管理您的 SCM 流程的 SCM 流程！

Answer 2

从 TFS 2010 中的分支运行构建时，我也遇到了这个问题。TFS 报告“$/Main/Product.sln 没有工作文件夹映射”解决方案原来是编辑构建定义如下（我使用的是“默认模板”构建过程模板——我没有用自定义模板尝试过）：

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

Answer 3

好的，结果出来了 - 我找到了解决方法。

由于我们遗留的构建过程（构建、复制、混淆、构建自定义安装程序、复制到放置文件夹），我无法轻松地将分支与主分支放在一起。它需要替换它。

所以，如果我有 Main 和 NewFeature，我希望取消映射 Main 并在其位置映射 NewFeature（即在构建服务器上使用“c:\Main”，并简单地更改出现在那里的源代码）

解决方案#1（最简单、最明显和合乎逻辑的解决方案）是使用这些映射：

• $/NewFeature -> c:\Main

预期结果：NewFeature 代码结构简单地替换了 Main，并且构建服务器不知道它在不同的分支上。

实际结果：失败并出现“即使您没有使用它，您也没有映射 $/Main”错误。

解决方案 #2 是这样做的：

• $/Main -> c:\IgnoreThisFolder
• $/NewFeature -> c:\Main

这可行（它会抑制警告，从而允许构建继续进行 MSBuild，而不知道它是在分支中构建的）。但是，它很丑陋，并且构建不必要地获取了所有 Main 分支源代码。

解决方案 #3（未经测试，除非我知道它会比 #2 好得多，否则无法尝试）是：

• 将所有源代码（从 $/Main、$/Branches/Feature）移动到 $/Branches/Main 和 $/Branches/Feature 以获得一致的层次结构深度，并重写 MSBuild 脚本以使用这些新路径.

• 希望我可以只映射到我需要的分支并编辑 TFSBuild.proj 以将其重定向到在该分支中构建。

  （编辑：是的，这很好用。我们现在重新组织了整个代码结构，以便所有内容（所有分支）都在单个团队项目中的共同根下，并且分支/构建不再是问题- 现在我们需要做的任何事情都很容易。诀窍是在层次结构中插入一个根文件夹，以便您可以在任何您喜欢的级别进行分支。我在构建脚本中添加了一个小调整，以便我们可以通过分支构建为 MSBuild 的参数，因此现在很容易构建任何变体。我们不想处理的任何分支都可以隐藏起来，构建服务器仍然很开心。）

总结 所有这些解决方案（使用技术术语）都很糟糕。您必须重新映射工作区（在这种情况下，这并不简单：需要 9 个映射条目，因此这是一个容易出错且乏味的事情），编辑 TFSBuild.proj，删除所有源代码，并使用 / 运行构建p:ForceGet=true 在分支之间切换构建。所以切换分支大约需要一个小时。难以置信 - 最多需要几分钟！

我意识到我们的项目远非理想设置，但我不敢相信在 TFS 中分支应该如此困难（在 SourceSafe、Accurev 和 Perforce 中是小菜一碟，为什么在 TFS 中如此痛苦?)。

其他人如何组织他们的 TFS 分支？你如何在分支之间切换开发人员？如何在分支之间切换服务器版本？真的要这么痛吗？

Answer 4

当您编辑构建定义时，有两个地方需要更改。

1. 源设置 - 指向您的新项目位置
2. 流程 -（加载有时需要一些时间，因此请耐心等待）在“必需”下，将“要构建的项目”位置更改为新解决方案。

希望这会有所帮助。

Answer 5

新更新：

正如在另一个答案中所报告的，我找到了一个解决方法，对于一个短暂的功能分支来说是可以的，但它确实不能很好地工作。从那以后我又回到了这个问题上，完整的解决方案非常简单：

在 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)。

解决方案很简单：我将 $(BuildProjectFolderPath) 替换为文件的本地路径（例如 D:\ServerBuildFolder\Main），以便在“本地空间”中解析相对引用（在应用映射后)，MSBuild 现在运行良好。

故事的寓意： 1) 如果您有任何机会希望在这些代码库之间进行任何类型的引用，则切勿使用多个团队项目。不要误以为新的团队项目会在应用程序/库之间提供某种无痛的逻辑区分。事实证明，额外的项目只是一场管理噩梦——大量额外的问题，绝对是零收益。 （在引擎盖下都是一大堆共享文件，所以所有工作项和源代码管理文件夹在所有项目中仍然可见（！），但它增加了一些砖墙，使项目间链接非常有问题）

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

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

（在我的辩护中，我会以这种方式开始 - 我正在使用旧设置。为了保护旧设置，这在纸上听起来不错，但不是微软支持的方法！）

Answer 6

我得到了这个错误，我所能理解的只是定义被破坏了。我只是重做了流程的东西（重新添加了我试图构建的解决方案）并重新映射了工作区，它又开始工作了。 HTH。