TFS 签到政策 - 最佳实践
是否有执行 TFS 签入政策的最佳实践？对于如何实施各种类型的政策及其利弊，有什么好的指南吗？
我特别想做的事情是确保代码编译（请注意，编译最多可能需要五分钟）并且遵循明显的编码标准（摘要标签必须存在，遵循命名约定等）。
Are there any best practices for enforcing a TFS check-in policy? Are there any good guides on how to implement various types of policies as well as their pros and cons?
Things I'd particularly like to do are ensure that code compiles (note that compilation can take up to five minutes) and that obvious bits of the coding standards are followed (summary tags must exist, naming conventions are followed, etc).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
TFS 2010（和 2008，但我没有使用过 2008）允许门控签入 - 这会在签入构建之前强制进行构建。
激活这是一个（合理）简单的过程，请参阅例如以下指南：
http:// /blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gate-check-in.aspx
http://intovsts.net/2010/ 04/18/the-erated-check-in-build-in-tfs2010/
在这一切之前有一个步骤是使这一切发生所必需的。这是 TFS 构建服务器设置。这可能是一个复杂的过程，具体取决于基础设施等。以下是 MSDN 指南：
http://msdn.microsoft.com/en-us/library/ms181712.aspx
优点是存储库中的代码相当稳定。对于大型团队来说，这可以节省大量时间。
为了实现这一好处，有很多缺点值得考虑。首先，安装和维护额外的构建服务器。这包括磁盘空间分配、补丁等。
其次是每个人签入文件所需的额外时间。在签入代码（并可供其他人获取）之前等待构建成功可能需要一段时间。
第三，当（不是如果）构建服务器不可用时，需要制定应急计划以允许开发人员继续工作。
要获得门控签到的奖励，需要执行很多额外的流程。然而，如果这个过程得到适当的管理，它可以导致更顺利的开发周期。
尽管我们不使用门控签入，但我们确实使用 TFS 构建服务器进行持续集成来执行计划构建。这最大限度地减少了对构建服务器的依赖，同时确保（以相当有效的方式）在构建中断后，我们会收到通知并可以尽快纠正它。这种方法使开发人员能够了解集成代码以及如何避免破坏存储库中的代码。
TFS 2010 (and 2008 but I have not used 2008) allows a gated checkin - which forces a build prior to the build being checked in.
Activating this is a (reasonably) straightforward process, see for example these guides:
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/
There is a step before all this which is required to make all this happen. That is a TFS build server setup. That can be a complex process depending on infrastructure etc. Here is an MSDN guide:
http://msdn.microsoft.com/en-us/library/ms181712.aspx
The pros are that the code in the repository can be reasonably stable. For a large team this can save a LOT of time.
There are a lot of cons worth considering for this benefit. Firstly, the installation and maintenance of an extra build server. This include disk space allocation, patches etc.
Secondly is the extra time required for each person to check in a file. Waiting for a build to succeed before the code is checked in (and available for others to get) can be a while.
Thirdly, when (not if) the build server is not available, a contingency plan needs to be in place to allow developers to continue their work.
There is a lot of extra process required to reap the rewards of gated checkins. However is this process is governed properly it can lead to a much smoother development cycle.
Although we do not use gated checkins, we do use a TFS build server for continuous integration to do scheduled builds. This minimises the dependency minute-to-minute on the build server while ensuring (with reasonably effectiveness) that after a build has broken, we are notified and can rectify it ASAP. This method empowers the developers to have an understanding of integrating code, and how to avoid breaking the code in the repository.
我觉得这个问题的前提是有些错误的。我认为这种性质的好问题应该是这样的：我的团队遇到了代码稳定性问题、变更集冲突、开发人员未运行测试、覆盖率低或向管理层报告的其他指标，我们希望使用 TFS 来帮助解决这个问题（那些） 问题）。是的，我确实意识到OP声明确保编译被视为一个目标，但这与拥有自动化构建服务器息息相关。
我会对任何在没有明确阐明的目的的情况下给开发人员的工作周期增加摩擦的功能提出质疑。尽管我从未使用过它们，但封闭式签到听起来像是一个寻找问题的功能。如果代码库的稳定性正在影响开发人员的生产力，并且您无法通过更改软件的组件化、开发团队结构或更好的分支策略来解决它，那么我想这是一个解决方案。我曾在一家大型商店工作过，负责一个全球项目，其中 ClearCase 是强制使用的工具，我也遇到过这种由公司引发的失败，但我工作的团队并没有安静或心甘情愿地去那里。
理想的政策是没有这样的政策。让开发人员无拘无束地工作，并尽可能减少摩擦。代码审查的作用远远超过没有灵魂的服务器强制执行的一组规则。一个支持测试且结构合理的团队将比封闭式签入在稳定性方面做得更多。支持分支和本地签入的工具使开发人员更容易尝试新事物，而不必担心破坏构建，这将有助于减轻导致大型项目死亡的技术债务。
I think the premise of this question is somewhat wrong. I think a good question of this nature should be something along the lines of; my team is having a problem with code stability, conflicting change-sets, developers not running tests, poor coverage, or other metric reporting to management and we'd like to use TFS to help solve that(those) issue(s). Yes, I do realize that the OP stated that ensuring compilation is considered a goal, but that comes part and parcel with having an automated build server.
I would question any feature that adds friction to a developer's work cycle without a clearly articulated purpose. Although I've never used them, gated check-ins sound like a feature in search of a problem. If the stability of your codebase is impacting developer productivity and you can't fix it by changing the componetization of your software, dev team structure, or a better branching strategy, then I guess it's a solution. I've worked in a large shop on a global project where ClearCase was the mandated tool and I've encountered that kind of corporate induced fail, but the team I worked on didn't go there quietly or willingly.
The ideal policy is not to have one. Let developers work uninhibited and with as little friction as possible. Code reviews do much more than a set of rules enforced by a soul-less server will ever do. A team that supports testing, and is properly structured will do more for stability than a gated check-in will ever achieve. Tools that support branching and local check-ins make it easier for developers to try new things without fear of breaking the build will help mitigate the kind of technical debt that kills large projects.
您应该查看“模式和实践：使用 Visual Studio Team Foundation Server 进行团队开发”
http://tfsguide 的第 8 章。 codeplex.com/
You should look at chapter 8 of "Patterns & practices: Team Development with Visual Studio Team Foundation Server"
http://tfsguide.codeplex.com/