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将会失败，而你的改动也无法被提交。
Figure 2：Build Definition中可以定义对Test的运行条件
对于Gated Check-in，在check-in时会弹出对话框确认是否需要Build这些变动。你也可以选择不Build，但是这需要较高的权限。一般不建议取消Build的过程。
Figure 3：Build Changes for Gated Check-in
好了，在设置好你的Build Definition之后我们来看看在做了一次无法通过Team Build的Check-in之后它如何反应？
Figure 3：TFS拒绝了无法通过Team Build的嵌入并且给了详尽的提示
我们这次的嵌入被TFS拒绝了。原因是“7/8 test(s) passed, 1 failed, 0 in conclusive”。原来是Test无法通过。而且后边还给出了Code Coverage：“33% of all code blocks covered”。以及本次嵌入对test的影响都有详尽的列出。那么现在怎么办呢？代码是被George嵌入但却被TFS暂时Shelve到服务器上了，然后George离开了。如何帮他修改问题呢？
Figure 4：Unshevlve Changes提供了让你得到这些被搁置的变动的机会
UnShelve就是将上一次Shelve到TFS上的变动（文件）拿回到你的工作区中。此时，我们可以通过点击Unshelve Changes链接来将George的变动导入到我们自己的工作区，然后修正后再次进行提交来帮助他将其变动提交到Source Control.
那么如果你提交的是可以通过Team build的变动呢？首先让我们来配置一下Build Notification吧，它连接到Team Build每次build的时候可以发出通知。选择“Start | All Programs | Microsoft Visual Stuido 2010 | Team Foundation Server Tools | Build Notification”，如下图：
Figure 5：运行Build Notification来通知每次Build
在Build Notification的配置界面选择TFS 地址和相应的项目以及Build Notification，这些配置了对于哪个项目的哪些Build我们会被通知。并且我们选择在Started和Finished时分别提示。
Figure 6： 配置Build Notification来通知Build
当Team Build完成了服务端的Build之后，如果build成功客户端的Build Notification将会在第一时间提示你有变动被嵌入，并询问是否更新你的工作区。
Figure 7：Gated Check-in被提交
Reconcile就好比于Get Latest，TFS会将这些提交的变动刷新到你的工作区。你也可以选择Ignore来忽略本次更新，并且在适当的时候到Build Exploer中点击相应Build来重新更新你的工作区（最简单的办法Get Latest：）
Figure 8：Reconcile Workspace
Gated Check-in提供给我们对项目开发过程中项目质量的初步保证。对于程序员的交付品通过Test以及MSBuild进行初步的管理来保证提交品是可以工作的，这在很大程度上减轻了我们持续集成的压力，并提供给我们很好的途径来提高持续集成过程中的各种测试工作。Team Build2010对于企业的自动化构建有很大的帮助，在接下来我们会从头对team build进行介绍。希望对你有所帮助：）
