Team Foundation Server 2010为基于Microsoft .NET开发平台进行开发的企业提供了完整的团队管理 平台和相应测试略，相比起TFS 2008来说的确有了非常大的改变。今天我们就来谈谈在Team Build 2010 中引进的Gated Check-in策略。
如果你的解决方案配置了Team Build，那么根据不同的Trigger会在不同的条件下触发team build. Team Build提供了以下几种不同的触发条件：
Figure 1: 不同的触发Team Build的条件选项
| Manual | 手动触发。普通的check-in不触发Team Build. |
| Continuous Integration | 持续集成-每次check-in都会触发一次Team Build。 |
| Rolling Builds | 滚动式构建-在每次build完成后的特定时间后自动触发。 |
| Gated Check-in | 只有在team build成功运行后才会提交。 |
| Schedule | 可设定build运行时间。 |
从上表我们可以看出，除了Geted Check-in其它的方式都是首先提交变化，然后运行Team Build。 Team Build运行的成功与失败并不影响本次Check-in。这就导致可能某个开发人员嵌入了他的代码，但是 Team Build没有通过，而后其它的嵌入全部无法通过Team Build-即便你的本次嵌入从单纯意义的build上 讲是可以通过Team Build的测试的。去修改Team Build报告的错误也要浪费很多的时间。那么Gated Check-in做了什么？它可以帮助我们做什么？
Gated Check-in实际上分三步，第一，将你的变化Shelve（搁置）到服务器上(注意：Shelve的代码相 当于给你的代码创建了branch)；其次，运行Team Build对你提交的改动后的解决方案进行编译；最后， 如果通过编译将改动提交给Source Control，否则不提交。这样做的好处是，保证每个人嵌入的是可以被 构建的独立的代码，不影响其他人的工作。
在Build Definition中，你仍然可以选择是否运行Test，运行什么样的Test等，如果测试失败Build是 否会失败。这样做提供了很好的机会让我们去创建多种不同的Build Definition.比如，你可以选择在普 通的Check-in中不运行Test，一次来节约服务器的消耗和提高对Check-in的响应。然后创建个 Nightly Build，让其在夜晚运行，包含这些Test。当然，这不是Gated Check-in所关心的。如果你设置了Fail Build On Test Failur，那么解决方案中如果有Test项，一旦失败的话Build将会失败，而你的改动也无 法被提交。