Question

我是Team Foundation Server的新手，我目前正在为我的项目设置自动构建策略。我遇到的一点困惑是如何设置与我们的源代码控制/开发结构相匹配的自动构建。

公司政策是在TFS项目下，我们包含文件夹'trunk'和'branches'。 'Trunk'代表并包含我们的生产代码。 “分支机构”显然正在开发分支机构。

我想为分支机构设置CI（持续集成）构建，并为'trunk'设置'Gated check-in'构建。我的想法是，当它需要推出生产时，这几乎可以消除“主干”构建的任何问题。但是我对这一切有几个问题：

1。我的策略是否有意义？（它是否过于冗余？是否会产生无法预料的问题？等等。）

2。 “合并”是否会构成触发CI或Gated构建的“签入”？如果开发人员将其开发分支合并为“trunk”，我希望这会触发主干构建。（也许这里的'Gated'构建是不必要的冗余？）

非常感谢您给我的任何指导。提前谢谢！

（开发环境：TFS 2010，VS 2010 Ultimate，Windows Server 2008 R2）

Answer 1

我是这么认为的。我们做了同样的事情并获得了很多成功。对于每天的开发来说，门控构建可能有点不稳定，因为在构建之后不断进行合并，但从分支到分支的合并角度来看，你不会有太多太多的问题。请记住，在签入期间签入不可合并的二进制文件时，如果启用了门控构建，则无法在本地保留更改。
是。合并在本地进行，然后检入合并的文件。这将触发您为该分支设置的任何构建。

我发现这些策略使代码库保持在一起。我遇到了gated构建不实用的问题，因为纠正某些问题变得非常困难。我不得不求助于关闭门控以使某些更改“合并”，然后再重新启用它。

Answer 2

任何源代码控制签入（包括合并）都将触发源控件更改事件并具有与之关联的变更集。

我们的正常设置

Project 
Project\trunk
Project\branches
Project\releases

Answer 3

我做了类似的事情，并将构建配置中的工作区目录设置为我需要的本地化。在主干上进行门控检查可确保您始终在主干分支中成功构建代码，因此我认为它不会过于冗余。