我们最近设置了 TFS 2013 并尝试设置门控签到。在我们的实验中，它正确地使构建失败并拒绝了错误的签入。但是，TFS Web 访问上的构建通知托盘图标和构建选项卡都显示失败，所有用户都是这样。当它只是一个人的“门”时，这会让每个人都认为“这个”构建被破坏了。它也会扭曲指标。
A) 为什么这是默认行为？这似乎非常适得其反和违反直觉。 [或者也许这不是默认行为，我们的设置被破坏了？]
B) 是否存在构建选项卡的配置，其中被拒绝的门控签入/构建仅对破坏它的人可见？
C) 我们如何让构建通知工具忽略门控故障？
【问题讨论】：
标签： tfs
a) 这是一个公共构建。为什么会失败。如果封闭式构建失败，则表明开发人员缺乏关注。他们在检查任何旧东西吗？他们是先运行单元测试吗？听起来你真的有质量问题。
这就是为什么门控构建仍然是公共构建。
b) 否 - 但是，如果任何人认为可能存在无法在本地捕获的问题，任何人都可以将私有构建发送到构建服务器。
c) 每个用户都可以取消选中对封闭式构建的监控。然而，我建议他们应该专注于不要让构建失败，而不是把它扫到地毯下......
归档的构建，甚至是封闭的构建，应该是例外而不是规则......
【讨论】：
MrHinsh 从哲学角度回答了我的问题，这导致我写了这篇文章：
[http://adamstephensen.com/2012/11/01/gated-checkins-mask-dysfunction/]
我原则上同意这篇文章。但是，由于我们正在一步步地攻击敏捷流程，因此我们暂时仍需要这种额外的安全检查。
以下不是我们想要的确切解决方案，但它是文章中的方法和我最初的问题的混合体。它不会强制进行门控签到，但它允许他们完成，为有风险的签到提供安全网。超出可构建能力的代码质量将通过本问题范围之外的其他机制来解决。
折衷的解决方案是正常签入“普通”更改（当然是在本地测试之后），然后启动 CI 构建。修复损坏的构建将是立即解决的高优先级。
但是任何不寻常的事情（配置更改、引用新的/不同的外部依赖项，或者只是开发人员不确定的任何事情）都会使用私有门控签入，但不会在主构建中使用，因为我们不希望每个人都被欺骗认为构建在被拒绝时被破坏。此构建定义是主构建定义的克隆，但在成功签入后，它使用以下链接链接主构建定义的构建：
虽然在大多数情况下主构建是多余的（可能存在竞争条件），但它解决了当前的需求。
【讨论】：