1

根据您的经验，指定工作项应在何处编码的最佳方式是什么？你使用特定的领域吗？我们目前在 WIT 中使用自定义的“要修复的版本”字段，但它与 Dev 或 Main line 代码分支没有直接关系。我们最终会沟通哪些版本（v6.1、v6.2 等）与哪些分支相关，但仍然需要完成“映射”。这实际上仅适用于已发布版本中的“Hot Fix”，因为该分支的名称与“要修复的版本”相同。如何指定工作项，以便开发人员很容易知道在哪里编码并提供最少的维护？

更新：澄清一下……我们有 Dev、Main 和 Release（每个版本一个）分支。我们 90% 的开发工作都是在 Dev 中完成的。一旦迭代结束，我们将 Dev 反向集成到 Main，但是我们不会在那时发布它。在 Main 上进行了一段时间的测试，并且可以在 Main 上修复选择的错误。这一切都在进行，而下一次迭代（新故事）在 Dev 中继续进行。一旦在 Main 上看起来不错，我们将分支到一个新版本（新的 Release 分支），并且 Main 上的开发将结束，直到下一次迭代开始，我们再次从 Dev 反向集成到 Main。当然，一旦在 Main 上解决了问题，我们就会将 Main 集成到 Dev。在任何时候，我们都可能在 Dev、Main 或已发布版本上存在我们想要修复的错误。我们在 Main、Dev 和 Release 中进行了错误修复，这让一些开发人员感到困惑。我们告诉他们“版本”，但他们必须知道未来或当前版本链接回哪个分支。这就是我试图找到 Task 工作项的最佳实践的地方。

4

3 回答 3

2

您可以在一个分支中拥有多个版本（变更集），但分支的扩散并不是一个好主意。

一个简单（但功能强大）的分支策略是创建一个主分支，然后创建 2 个子分支：1）Dev，2）QA 现在问题是非问题。开发人员在 Dev 分支中工作。当他们准备好时，他们会将更改反向集成到 main。然后将更改前向集成到 QA。如果构建通过了 QA，那么它就可以投入生产。

一些组织将采用特殊的分支实践，例如为新的主要版本创建分支，甚至为特殊功能创建分支。这些遵循相同的反向集成到 main 的过程（以及适当的后续正向集成开发分支）。

构建可以链接到变更集。如果特定的构建有错误，开发人员会查找变更集编号，将其从版本控制中拉下来，检查将其与错误的适当工作项相关联的工作，然后重新构建它。这个新的“错误修复”版本现在有一个唯一的构建 ID 和与之关联的变更集 ID。

于 2011-04-27T22:22:36.667 回答
0

这真的取决于你的商店；我们的环境适用于迭代构建，因此错误修复总是进入最新的分支（通过日期戳命名 - IE Branch_05252011 左右）。

如果您有其他类型的版本控制/分支策略，最好的选择是将所需的修复分支放在标题中：

V6.2 - Fix the ItExplodedException occuring in SomeClass

或者，我相信 TFS 甚至可以提供一个专门的下拉菜单，您可以在使用自定义内容创建工作项时填充该下拉菜单。然后，您可以使用要定位的分支填充它。

于 2011-04-27T22:12:44.480 回答
0

这是一个非常有效的解决方案：使用 TFS Power Tools 设置签入策略，并将自定义路径策略与工作项查询策略相关联，以便分支的所有签入都需要与属于特定于分支的查询。这样，如果签入没有与分支匹配的工作项，则不会被允许。可以使用您需要的任何标准来定义查询，并且可以根据需要更新查询本身并重新分配给不同的分支。

但是需要注意的是：查询本身是在客户端评估的，因此作为管理员，您可以更新查询以阻止或允许某些项目进入分支，但开发人员将需要刷新团队资源管理器以更新他们的查询，否则它可以允许未经授权的项目进入，也可以阻止已授权的项目。我正在为此问题寻找的一种解决方案是添加一个自定义签入策略，该策略将始终得到满足，但同时会导致 VS IDE 刷新团队资源管理器。我已要求 MS 将此直接添加到他们的 TFS Power Tools 工作项查询签入策略中，但他们没有回应。

于 2014-08-18T21:19:55.377 回答