TFS 中具有多个版本的迭代答案

【问题标题】：Iterations with multiple releases in TFSTFS 中具有多个版本的迭代
【发布时间】：2015-02-10 15:32:54
【问题描述】：

应该如何在 TFS（特别是 Visual Studio Online）中构建版本和迭代，其中迭代中的一些工作计入一个版本，而其余工作计入另一个版本？？ p>

一些背景知识：我正在与一个拥有 2 个代码分支的团队合作：第一个分支用于维护，每 2 周发布一次，第二个分支用于长期“2.0 版”项目（发布时间为 6个月）。我们在每次迭代中都在两个分支中工作，并且我们都在维护和“2.0 版”项目上工作。

我们当前的迭代树遵循\<release>\<iteration> 模式，如下所示：

当 Iteration 1 中的某些工作不会在 Maintenance Release 1 中发布，而是在未来的“2.0 版”版本中发布时，就会出现问题。

我希望结构更像这样，至少在概念上，但不重复迭代：

我考虑过的尝试是：重组我们的团队以拥有仅维护和仅“2.0 版”的开发人员不是一种选择。将我们的迭代分解为仅维护和仅“2.0 版”是不现实的（我们需要快速周转维护，因此需要在每次迭代中进行工作）。计划 2 个并发迭代似乎有点过头了。

【问题讨论】：

【解决方案1】：

最终你需要通过没有两个分支来解决这个问题。您应该拥有一个好的产品版本，并将 v2 的功能隐藏在功能标志后面。然后，您可以将任何工作、功能或维护添加到每个增量中，并在每个 sprint 结束时交付。此时，您可以选择与维护工作一起提供的功能。

您所描述的问题然后就消失了。

哦，您可能想使用标签来标记您的维护 (Opex) 工作以供以后使用。

【讨论】：

很好的建议，但不幸的是，我们的 V2 更改过于复杂，无法在同一个分支中管理。我正在查看标签，我对它们的发布跟踪不满意，但到目前为止，它们看起来是我最好的替代品。

【解决方案2】：

我通过迭代将分支拆分为迭代的不同子节点来解决此限制。毕竟，树中并没有真正的“类型”概念，所以节点可以是任何你想要的。

另外，我为分支工作保留了单独的积压工作。

【讨论】：

【解决方案3】：

您似乎在人为地将迭代结构与分支结构联系起来。

如果您在迭代 1 中同时为“分支 1”和“分支 2”工作，那么为什么不使用单个迭代，而使用两个区域路径呢？这样，您就可以在同一迭代中为这两个领域提供用户故事和任务。

【讨论】：