TFS 自动构建策略问题
我是 Team Foundation Server 的新手，目前正在为我的项目设置自动构建策略。我遇到的一点困惑是如何设置与我们的源代码控制/开发结构相匹配的自动化构建。
根据公司政策，在 TFS 项目下，我们包含文件夹“trunk”和“branches”。 “Trunk”代表并包含我们的生产代码。 “分支机构”显然拥有正在开发的分支机构。
我想为分支设置 CI（持续集成）构建，并为“主干”设置“门控签入”构建。我的想法是，这实际上将消除在推出到生产环境时“主干”构建的任何问题。不过，我对这一切确实有几个问题：
1。我的策略有意义吗？（是否太多余？是否会产生不可预见的问题？等等）
2. “合并”是否构成“签入”，从而触发 CI 或门控构建？ 如果开发人员将其开发分支合并到“主干”中，我希望这能触发主干构建。 （也许这里的“门控”构建是不必要的冗余？）
非常感谢您能给我的任何指导。先感谢您！
（开发环境：TFS 2010、VS 2010 Ultimate、Windows Server 2008 R2）
I'm new to Team Foundation Server, and I'm currently working on setting up an automated build strategy for my project. One bit of confusion I'm having is how to setup automated builds that match our source control/development structure.
It is company policy that under a TFS project, we include the folders 'trunk' and 'branches'. 'Trunk' represents and contains our production code. 'Branches' obviously holds branches under development.
I'd like to setup CI (continuous integration) builds for branches, and a 'Gated check-in' build for 'trunk'. My thinking is that this will virtually eliminate any problems with 'trunk' builds when it's time to roll-out to production. I do however have a few questions about all of this:
1. Does my strategy make sense? (Is it too redundant? Does it create unforeseen issues? etc.)
2. Does a 'merge' constitute a 'check-in' that will a trigger a CI or Gated build? If developers will merge their development branches into 'trunk', I'd like this to trigger the trunk build. (Perhaps a 'Gated' build here is an unnecessary redundancy?)
Any guidance you can give me is most appreciated. Thank you in advance!
(Development environment: TFS 2010, VS 2010 Ultimate, Windows Server 2008 R2)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想是的。我们做同样的事情并取得了很大的成功。对于日常开发来说，门控构建可能有点不稳定，因为构建后会不断进行合并，但从分支到分支合并的角度来看，您不会遇到太多问题。请记住，当您在签入期间签入不可合并的二进制文件时，如果启用了门控构建，则无法在本地保留更改。
是的。合并在本地进行，然后您签入合并的文件。这将触发您为该分支设置的任何构建。 是的
我发现这些策略使代码库保持良好的组合。我遇到过门控构建不切实际的问题，因为纠正某些问题变得非常困难。我不得不关闭门控来“合并”某些更改，然后重新启用它。
I think so. We do the same thing with a lot of success. The gated builds can be kind of wonky for every day development as there is constant merging going on after builds but from a branch-to-branch merging standpoint, you won't have too many issues. Keep in mind, when you check in a unmergable binary file during a check-in you cannot preserve your changes locally, when a gated build is enabled.
Yes. Merging happens locally and then you check in the merged files. This will trigger whatever build you have setup for that branch.
I have found that these strategies keep the code base pretty put together. I have run into issues where gated builds just aren't practical because it becomes very difficult to correct certain issues. I've had to resort to turning off the gated to get certain changes "merged" in and then re-enabling it afterwards.
任何源代码管理签入（包括合并）都将触发源代码管理更改事件并具有与其关联的更改集。
我们的正常设置
Any source control check in (including merge) will trigger a source control change event and have a changeset associated with it.
Our normal setup
我做了类似的事情，并根据需要将构建配置中的工作区目录设置为本地化。在主干上进行门控签入可确保您始终在主干分支中成功构建代码，因此我认为这并不太多余。
此链接包含大量信息，可帮助我建立合并策略。
I do something similar and set the workspace directory in the build configuration as localized as I need it. Having a Gated check-in on trunk ensures that you always have successfully building code in your trunk branch, so I don't think it's too redundant.
This link has a bunch of information that helped me with establishing a merge strategy.