TFS 值机政策最佳实践/您的经验

Question

我们将在一个新项目中使用 TFS 2010，我正在寻找有关在团队开发时使用策略签入选项的最佳实践和知识/经验。 我找到了有关所有这些的信息，但关于最佳实践以及开发团队对政策的看法和经验的信息并不多，他们使用过，也许应该使用过。

• 您使用了哪些策略？
• 您的体验如何？
• 您会推荐什么？

例如，您是否使用过 Microsoft 最低推荐规则，并且您都使用过它们吗？

我们非常感谢您提供信息和您的经验。

Answer 1

最基本的入住政策是：

• 评论政策 - 所有签到都需要 cmets。
• 工作项关联 - 这应该是强制性的，因为没有它，您无法将更改集分组到特定的工作流。您需要能够执行此操作才能批量合并和回滚更改。
• 门控签入 - 虽然不是这样的策略（您需要创建门控构建），但它可以防止开发人员签入破坏构建的代码。如果您在代码库中创建了链接构建，则可以通过再次签入来确保您的解决方案永远不会被破坏。我已经做到了，而且效果很好。

还有很多其他的（我们使用 Gemini 项目关联策略），您可以像我们一样编写自己的。这并不难，您可以根据需要对其进行调整。

Answer 2

这更像是一个讨论问题，这不是 StackOverflow 通常想要的问题类型，但我会咬一口。

对我来说有意义的政策是：

• 构建策略
  • 此策略可防止在有人破坏构建后生成失败构建的构建队列。实际上，系统会警告您构建当前已损坏，以便有人可以在继续之前修复构建。
• 工作项关联
  • 我们需要工作项关联，以确保我们可以将签入跟踪到正在完成的工作，并通过它跟踪到测试用例。
• 工作项查询
  • 我们希望人们从当前的冲刺/迭代中选择他们的工作。因此，验证人们签到的工作实际上是预先批准的工作是很方便的。
• Custom Path Policy
  • 我们偶尔会在包含多个项目的团队项目中使用此策略，并且我们希望提高一个项目的质量或安全性，但不想打扰另一个项目。或者防止在当前版本分支上进行某些签入，但不希望对仍在维护的旧版本执行如此严格的政策。

我们验证了一些您可以通过签入策略通过失败 CI 构建来执行的操作。这样做主要是为了节省开发人员机器上的时间。

• 代码分析策略。
  • 我们没有为此使用签入策略，而是使用 CI 构建，如果某些代码分析规则被破坏，该构建将失败。这允许我们让开发人员构建跳过每次构建的代码分析。人们将很快学会如何防止这些规则被触发。

我们没有使用任何其他政策。我们有时会使用 Require comment for change set 策略，但大多数团队实际上在一段时间后就不需要此策略。大多数人都不赞成在签到时没有 cmets，这会自行解决。

我们有几个项目完成了时间跟踪（针对 MSF CMMI），我们使用了custom policy to ensure people updated their hours on every checkin。

我们没有使用任何政策来强制执行代码覆盖率或警告数量。如果需要，可以通过构建过程自定义将这些添加到构建中。

我们在需要额外验证的分支机构上使用门控签到。比如发布分支和后续自动部署的分支。

我们经常允许开发人员绕过任何签入政策而不会受到处罚。门控签到也是如此。明智地使用这些权利取决于开发人员。在被团队注意到之前，你不能经常破坏部署；）。

也有一些有趣的自定义政策，但我知道只有少数人真正使用了这些政策。

• Merge only policy
  • 此策略允许您指定几个分支，它们只能接收另一个分支上已签入工作的合并。
• Forbidden Patterns Policy
  • 我有时会使用这些来确保没有将 /bin/debug、.exe 或 .dll 签入 TFS 中的 //src/ 文件夹。

还有一些来自第 3 方的政策，但我从未使用过这些政策。其中包括：

• The Checkin Policy Pack 并且该页面列出了一些我从未使用过的额外策略。

不使用太多第 3 方策略的原因之一是所有团队成员都需要在他们的计算机上安装策略。 Team Foundation Server Power Tools 可以帮助您进行分发，但默认情况下，这些并不是在所有开发人员工作站上部署和配置的。

还有available in blog form。

Answer 3

尝试每个签到政策，看看它们是否为您的团队提供价值。

我们的一些团队项目只需要签入评论。有些需要注释和工作项。有些需要成功构建。这完全取决于团队需要什么。

不要试图遵循别人的最佳做法。确定什么在您的环境中有效。