是否有执行 TFS checkin 策略的最佳实践？关于如何实现各种类型的政策及其优缺点，是否有任何好的指南？
我特别想做的事情是确保代码编译(注意编译最多可能需要五分钟)并且遵循明显的编码标准(必须存在摘要标签，遵循命名约定等) .
最佳答案
TFS 2010(和 2008，但我没有使用 2008)允许门控 checkin - 这会在 checkin 构建之前强制构建。
激活这是一个(相当)简单的过程，例如，请参阅这些指南: http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx http://intovsts.net/2010/04/18/the-gated-check-in-build-in-tfs2010/
在所有这一切之前有一个步骤是实现这一切所必需的。这是一个 TFS 构建服务器设置。这可能是一个复杂的过程，具体取决于基础设施等。这是一份 MSDN 指南: http://msdn.microsoft.com/en-us/library/ms181712.aspx
优点是存储库中的代码可以相当稳定。对于大型团队，这可以节省大量时间。
为了实现这一优势，有很多缺点值得考虑。首先，安装和维护一个额外的构建服务器。这包括磁盘空间分配、补丁等。 其次是每个人 checkin 文件所需的额外时间。在 checkin 代码(并可供其他人获取)之前等待构建成功可能需要一段时间。 第三，当(不是如果)构建服务器不可用时，需要制定应急计划以允许开发人员继续他们的工作。
要获得门控签到的返回，需要很多额外的过程。然而，如果这个过程得到适当的管理，它可以导致更顺畅的开发周期。
虽然我们不使用门控 checkin ，但我们确实使用 TFS 构建服务器进行持续集成以执行计划构建。这最大限度地减少了对构建服务器的依赖，同时确保(合理有效地)在构建失败后，我们会收到通知并尽快纠正它。这种方法使开发人员能够了解集成代码，以及如何避免破坏存储库中的代码。
关于c# - TFS checkin 政策 - 最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5332695/