TFS签入策略的最佳实践/你的经历

Question

我们要使用TFS 2010的一个新项目，我正在寻找有关作为一个团队开发时使用的策略检查中选择一个最佳实践和知识/经验。 我发现了所有这些信息，但没有提供关于最佳实践的大量信息，以及开发团队对政策的意见和经验，他们使用过或可能应该使用这些政策。你用

• 哪些政策？
• 你有什么经验？
• 你会推荐什么？

例如，您是否使用了微软最低推荐规则，您是否全部使用它们？

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

Answer 1

最重要的签入策略是：

• 评论政策 - 要求对所有签到意见。
• 工作项目关联 - 这应该是强制性的，因为没有它你不能将更改集合分组到特定的工作流。你需要能够做到这一点，以合并和批量回滚更改。
• 封闭式入住 - 尽管不是政策本身（你需要创建一个门版本）它可以防止开发商在打破编译代码检查。如果您在代码库中创建了链接版本，则可以确保您的解决方案永远不会因重新登录而中断。我已经做到了，它的工作原理。

还有很多其他的（我们使用双子座项目协会政策），你可以写你自己的。这并不难，你可以量身定制它们。

Answer 2

尝试每个签入的政策，看看他们是否给你的团队提供价值。

我们的一些团队项目只需要在评论检查。有些需要评论和工作项目。有些需要成功构建。这完全取决于团队的需求。

不要试图遵循别人的最佳做法。确定什么在你的环境中起作用。

Answer 3

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

，对我有意义的政策是：

• 构建政策
  • 此策略将阻止失败构建队列建立有人打破了构建之后。实际上，您会被警告该构建目前被破坏，以便有人可以在继续之前修复构建。
• 工作项目协会
  • 我们需要工作项关联性，以确保我们可以追踪正在做的通过对测试用例签工作。
• 工作项查询
  • 我们希望人们选择从目前的冲刺/迭代他们的工作。因此，验证工作人员实际上是否核准工作是很方便的。
• Custom Path Policy
  • 我们在那个房子里不止一个项目，我们想要提高质量或安全上的一个项目，但都没有兴趣打扰其他项目组项目，而使用此政策一旦。或者阻止当前版本分支上的某些签名，但不希望在仍旧保留的旧版本上使用这样严格的策略。

我们通过失败的CI构建，而不是验证的几件事情，你可以通过签入的政策办。这主要是为了节省开发者机器上的时间。

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

我们不使用任何其他政策。对变更集策略的需求评论是我们有时使用的，但大多数团队在一段时间后实际上不需要针对此策略。没有对签入评论被大多数人所诟病，这就解决了。

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

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

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

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

这里也有一些有趣的定制政策，但我知道只有少数人竟然会使用这些。

• Merge only policy
  • 此策略允许您指定几个分支只能接收工作已经检查了另一个分支的合并。
• Forbidden Patterns Policy
  • 我有时使用这些以确保没有/bin/debug，.exe或.dll被检查到TFS一个//src/文件夹。

有来自第三方几个政策，但我从未使用过这些。这些包括：

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

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

另外available in blog form。