严格意义上讲，Gated Check-in（门控式签入，呵呵，这是我自己的翻译，英文名很好理解，但翻译起来真难啊！最近发现了Gated Check-in的官方翻译因该是 - 封闭签入，感觉挺别扭的没俺翻译的好，呵呵！）不应该算是测试的一部分，它是Team Foundation Server（以下简称为TFS）提供的一种代码check in(签入，这是最常见到的对check in的翻译，在本文中还是直接使用其英文，因为这是在平常开发中最常使用的称呼)的方式，即在代码check in之前，先将提交的代码更改与现有代码进行merge，然后对merge后的代码进行Build，如果Build成功则check in，否则就会报错并且不check in所提交的代码。
表面上看是与测试没有关系，但实际上它和测试以及产品质量的关系还是蛮大的。因为毕竟代码check in是整个开发过程中发生最为频繁的操作，每次check-in代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in中提到的“Build成功”，实际上包含两部分内容：编译成功和测试用例执行成功。
启用Gated Check-in功能的方法是很简单的，只需要在Build Defintion的Trigger标签页中选择“Gated Check-in”，例如：我定义了自己的一个Build 叫做“DogfoodBuild”，它的定义如下图所示：
369
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
