内部应用程序的TFS 2010分支模型

Question

这不是我没有任何想法的问题，而是我想提出一个模型，看看它是否获得批准，或者任何人都可以看到它的问题或有更好的建议。他们说，最好仔细选择您的分支模型，以避免将来出现麻烦。

因此，我们有一个内部应用程序，仅向客户发布了一个版本（最新版本），并且基本上有两种开发活动：主要活动是针对下一个版本，并且通常包括新功能和更正修订它是计划好的，第二个是未计划的，是关于维护的，其中包括生产中当前版本的修补程序。

经过长期研究，我们决定使用 Main 主干，从中分支出两个子分支：开发和维护（或修补程序）。正如指南中所介绍的那样，每日开发将在 Development 分支中进行，只要我们有准备好用于下一版本的功能，我们就会在该分支中进行反向集成（RI）。在发布之前，反向集成将停止，并且代码将在 Main 分支中稳定下来。从 Main 发布后，将从 Main 到 Development 和 Maintenance 的前向集成（FI）。< / p>

任何修补程序都只会在 Maintenance 中进行，并且根据修补程序（例如，如果我们希望将其保留在代码库中），我们将对 Main 进行RI从那里FI进入开发。

现在一切看起来都很好，至少在纸面上，所以我想听听其他人对此模型的看法。

例如，我们还将考虑另外一个分支 Release ，在该分支中，代码的稳定发生在正式发布之前（而不是直接在 Main 中工作），当然，我们将从此处发布到生产，然后对 Main 进行RI，然后对FI进行 Development 和 Maintenance ，但是我们不是确定这会带来好处还是会增加复杂性？

并假设开发中将有某些功能尚未准备就绪或不希望用于下一版本，这意味着我们将不得不对相关的变更集进行一些“挑选”所需的功能，但是根据文档，这并不是太好。有什么建议吗？

我再次知道这不是一个简单，直接的问题，而是一个开放的问题，我仍然希望听到任何有类似经验的人的来信。预先感谢您的关注。

Answer 1

您是否已阅读《 TFS ALM游骑兵分支指南》文档？您提议的内容看起来很像他们的“标准分支计划”，尽管它们鼓励同时发布和“服务包”分支（类似于上面的“发布”和“维护”分支）。

http://vsarbranchingguide.codeplex.com/

我已经在一些客户中实施了标准分支计划，但没有遇到任何问题。如果您打算采用并行工作流（功能人员等），则分支机构指南对此也有明确的计划。

要考虑的另一件事可能是阶梯模型，在该模型中，您在每个发行版中创建新的Dev分支，并将旧的分支冻结为发行版。这样可以避免RI，因为您可以只对旧版本进行Hotfix，然后在必要时将FI修复到新的Dev分支。我也曾经在这个模型中工作过，而且很棒。