是否有执行TFS签到政策的最佳做法？是否有关于如何实施各种政策及其利弊的良好指南？
我特别想做的事情是确保代码编译（注意编译可能需要长达五分钟）并且遵循编码标准的明显位（必须存在摘要标记，遵循命名约定等）
答案 0 :(得分：17)
2010年TFS（以及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构建服务器进行持续集成以执行预定构建。这最大限度地减少了构建服务器上的每分钟依赖性，同时确保（具有合理的有效性）在构建中断后，我们会得到通知并且可以尽快纠正它。这种方法使开发人员能够理解集成代码，以及如何避免破坏存储库中的代码。
答案 1 :(得分：5)
我认为这个问题的前提是有些错误的。我认为这个性质的一个好问题应该是这样的。我的团队遇到代码稳定性问题，变更集冲突，开发人员未运行测试，覆盖率差或其他指标报告给管理和我们想使用TFS帮助解决这些问题（那些）问题。是的，我确实意识到OP声明确保编译被认为是一个目标，但这与自动构建服务器有关。
我会质疑任何在没有清晰明确目的的情况下为开发人员的工作周期增加摩擦力的功能。虽然我从未使用它们，但是门控签到听起来像是一个搜索问题的功能。如果您的代码库的稳定性影响了开发人员的工作效率，而您无法通过更改软件的组件，开发团队结构或更好的分支策略来解决它，那么我想这是一个解决方案。我曾在一家大型商店工作过一个全球项目，其中ClearCase是强制性的工具，我遇到过那种企业导致的失败，但我所工作的团队并没有安静或自愿地去那里。
理想的政策不是拥有一个。让开发人员不受约束地工作，并尽可能减少摩擦。代码评论所做的远远超过无灵魂服务器所执行的一系列规则。支持测试并且结构合理的团队将比门控签到所能实现的稳定性更高。支持分支和本地签入的工具使开发人员可以更轻松地尝试新事物，而不必担心破坏构建将有助于减轻导致大型项目丧失的技术债务。
答案 2 :(得分：4)
您应该查看“模式和实践：使用Visual Studio Team Foundation Server进行团队开发”的第8章