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