是否有执行 TFS 签入政策的最佳做法？有没有很好的指南来说明如何实施各种类型的政策以及它们的优缺点？
我特别想做的事情是确保代码编译（注意编译最多可能需要五分钟）并遵循明显的编码标准（必须存在摘要标签，遵循命名约定等） .
【问题讨论】：
TFS 2010（和 2008，但我没有使用 2008）允许进行门控签入 - 这会在签入构建之前强制构建。
激活这是一个（相当）简单的过程，例如，请参阅以下指南： 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
优点是存储库中的代码可以相当稳定。对于大型团队来说，这可以节省大量时间。
为了这个好处，有很多缺点值得考虑。首先，安装和维护额外的构建服务器。这包括磁盘空间分配、补丁等。 其次是每个人签入文件所需的额外时间。在签入代码（并且可供其他人获取）之前等待构建成功可能需要一段时间。 第三，当（不是如果）构建服务器不可用时，需要制定应急计划以允许开发人员继续他们的工作。
要获得门控签到的奖励需要很多额外的过程。然而，如果这个过程管理得当，它可以使开发周期更加顺畅。
虽然我们不使用门控签入，但我们确实使用 TFS 构建服务器进行持续集成以执行计划构建。这最大限度地减少了构建服务器上的依赖关系，同时确保（具有合理的有效性）在构建失败后，我们会收到通知并可以尽快纠正它。这种方法使开发人员能够了解集成代码，以及如何避免破坏存储库中的代码。
【讨论】：
我认为这个问题的前提有些错误。我认为这种性质的一个好问题应该是这样的：我的团队在代码稳定性、变更集冲突、开发人员未运行测试、覆盖率低或向管理层报告其他指标方面遇到问题我们希望使用 TFS 来帮助解决这个问题（那些） 问题）。是的，我确实意识到 OP 声明确保编译被视为一个目标，但这与拥有自动构建服务器是必不可少的。
如果没有明确的目的，我会质疑任何会增加开发人员工作周期摩擦的功能。虽然我从未使用过它们，但门控签到听起来像是一个寻找问题的功能。如果您的代码库的稳定性正在影响开发人员的生产力，并且您无法通过更改软件的组件化、开发团队结构或更好的分支策略来解决它，那么我想这是一个解决方案。我在一家大型商店工作过一个全球项目，其中 ClearCase 是强制工具，我遇到过这种公司引发的失败，但我工作的团队并没有悄悄地或心甘情愿地去那里。
理想的政策是没有。让开发人员不受约束地工作，尽可能减少摩擦。代码审查所做的远比一套由没有灵魂的服务器强制执行的规则所做的要多。一个支持测试且结构合理的团队在稳定性方面所做的工作将比门控签到所能达到的更多。支持分支和本地签入的工具使开发人员可以更轻松地尝试新事物而不必担心破坏构建，这将有助于减轻那种扼杀大型项目的技术债务。
【讨论】：
您应该查看“模式与实践：使用 Visual Studio Team Foundation Server 进行团队开发”的第 8 章
【讨论】：