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

Question

我们将使用TFS 2010进行新项目，并且我正在寻找在团队开发时使用策略检查选项的最佳实践和知识/经验。 我已经找到了关于所有这些的信息，但没有真正关于最佳实践的信息以及开发团队对政策的看法和经验，他们使用过，也许应该使用这些信息。

• 您使用了哪些政策？
• 你的经历是什么？
• 你会推荐什么？

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

信息和您的经验表示赞赏。

Answer 1

最重要的登记政策是：

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

还有很多其他人（我们使用Gemini项目关联政策），你可以像我们一样自己编写。这并不难，你可以根据自己的需要量身定做。

Answer 2

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

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

• 制定政策
  • 此策略可防止有人破坏构建后构建失败的构建队列。实际上，您会收到警告，说明构建当前已损坏，因此有人可以在继续之前修复构建。
• 工作项目关联
  • 我们需要工作项目关联，以确保我们可以跟踪签到工作，以便通过测试用途进行工作。
• 工作项查询
  • 我们希望人们从当前的sprint / iteration中选择他们的工作。因此，验证人们正在检查的工作实际上是预先批准的工作是很方便的。
• Custom Path Policy
  • 我们偶尔会在包含多个项目的团队项目中使用此策略，并且我们希望在一个项目中提高质量或安全性，但对打扰其他项目不感兴趣。或者是为了防止在当前版本分支上进行某些签入，但是对于仍在维护的旧版本不希望采用此类严格的策略。

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

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

我们没有使用任何其他政策。需要对变更集策略发表评论是我们有时会使用的，但大多数团队在一段时间后实际上并不需要这样的政策。对签到没有任何评论是大多数人不赞成的，这解决了。

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

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

我们在需要额外验证的分支机构上使用Gated Checkins。例如发布分支和分支，然后自动部署。

我们经常允许开发人员绕过任何签到政策而不受处罚。门控Checkins也是如此。开发人员可以明智地使用这些权利。打破部署是在团队注意之前你不能经常做的事情;）。

也有一些有趣的自定义政策，但我知道只有极少数人实际使用过这些政策。

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

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

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

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

available in blog form。

Answer 3

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

我们的一些团队项目只需要签到一条评论。有些需要评论和工作项。有些需要成功构建。这一切都取决于团队的要求。

不要试图遵循别人的最佳做法。确定适合您环境的功能。