TFS 每个功能分支策略，适合具有独立功能时间表的多个环境答案

【问题标题】：TFS Branch-Per-Feature Strategy That Fits Multiple Environments With Independent Feature TimetablesTFS 每个功能分支策略，适合具有独立功能时间表的多个环境
【发布时间】：2011-03-25 01:40:34
【问题描述】：

关于 TFS 分支策略有几个/很多问题，但我无法提出适合我的方案的策略。我的 TFS 项目由一个解决方案组成，其中包含一个 Web 项目、一个业务层项目和一个数据层项目。该项目是报告的门户。报告主要隔离在项目的子文件夹中。然而，整个项目中有一些功能，例如会话管理。在给定的时间段内，工作流可能会发生如下：

稳定的代码快照。
开始编写报告 A。
开始编写报告 B。
需要将包含报告 A 的项目推送到我们的 QA 环境中。
需要将包含报告 A 和报告 B 的项目推送到我们的 QA 环境中。
仅包含报告 B 的项目需要推送到我们的生产环境。

所以基本上，每份报告都有一个完全独立的时间表。我需要能够独立地将代码分支发布到我们不同的环境中。目前，我们没有分支 - 如果项目在报告尚未准备好但包含在项目中时发布，我们只是不添加指向新功能的链接。不是最好的情况。

我最初采用的分支策略是让 Main 位于 QA 和 prod 环境之间，基本上只是一个在分支到生产分支进行生产发布之前合并的容器。每个报告都将在 main 的一个分支上开发。对于我们的测试和 qa 环境，将创建一个来自 main 的分支，并将适当的开发分支合并到这个“提议的更新”分支中。这不起作用，因为我将开发/功能分支合并到一个不是父分支的分支中。我不能在这个级别拥有 Main，因为一个报告可能需要数周的时间来开发，而另一个报告可能在一个时间表上，它已经开发并在几天内完成了整个流程并推向生产。我用于测试和 qa 的“建议更新”分支需要能够通过仅合并适当的开发分支来独立创建。

我对分支/合并的唯一经验是主+开发对分支，所以我在这里非常不适应。如何设置我的分支，以便能够在独立时间表上合并功能而不会卡住，并且代码在准备好之前就发布到环境中？

如果重要的话，我们现在正在参加 TFS 2008，并希望很快参加 TFS 2010。不过，这是我们当前 TFS 2008 服务器的迫切需要。

【问题讨论】：

标签： tfs branch merge

【解决方案1】：

我对所有事情都不是很清楚；阅读理解等等。

据我了解，您当前的流程是Dev -> Test -> QA -> Production。开发人员处理代码，将其推送到可以对其进行测试的环境。一旦满意，他们就会将其推送给 QA，并在代码通过时将其投入生产。

此外，您有几个“团队”（1 个或多个开发人员）必须处理单独的报告，每个报告最终都必须通过上述流程进入生产阶段。团队可能正在处理与其他所有团队不同的代码，或者团队可能会发现在其他团队达到稳定之前他们无法推进他们的代码。

如果我负责此解决方案的分支，我会推荐以下方法。

首先，创建一个生产分支。此分支仅包含生产代码。只有您的 QA 团队会接触此分支。

接下来，创建一个 QA 分支。该分支也由 QA 团队单独维护。他们手动将测试代码合并到这个分支中，运行他们的质量保证测试，然后与生产合并。每次它们与 Production 合并，或测试代码被 QA 接受时，都会为分支应用一个标签。如果测试代码失败，分支将恢复到之前的标签。

开发团队管理自己的分支机构。它们是从最新标签的 QA 分支创建的。这可确保他们使用最新批准的代码。开发人员在这个分支上工作和测试。如果团队相互依赖，他们应该在同一个分支上工作，除非很明显从他们共享的 Dev 分支创建辅助分支会更容易。一旦 Dev 分支满足为开发人员设置的里程碑，应通知 QA 该分支已准备好与 QA 合并以进行测试。

或者， 根据开发的复杂程度，您甚至可以考虑合并 QA 和 Production 分支。通常，向分支添加标签以指示稳定的、值得生产的构建是一件简单的事情。它还使分支策略尽可能简单，这总是一件好事。

【讨论】：

我不确定这是否有助于解决这样一个事实，即如果 QA 分支有 2 个新功能，那么只有 1 个新功能应该被提升到生产环境。
@rchern 好吧，这取决于。进出 QA 分支应该是原子的。否则，当另一个团队的工作在测试中途混在一起时，你怎么能测试一个团队的工作呢？您要么必须创建单独的 QA 分支，这些分支必须在 QA 与生产合并之前合并，要么将开发分支排队等待 QA。这不一定是分支/合并的问题，更多的是关于过程。请注意，您始终可以进行“反向集成”，您可以将 QA 分支（从开发团队 1 更新）与 QA 分支测试开发团队 2 的工作重新集成。
@rchern BTW，MS 的“ALM Rangers”可能是一个很好的资源。这是他们 2010 年的指导 tfsbranchingguideiii.codeplex.com，它仍然适用于（在某种程度上）到 2008 年；我敢肯定，如果您与他们联系，如果您有问题似乎无法得到足够的答案，他们会很乐意提供帮助。
是的，我已经阅读了分支指南。关于多个 QA 分支：是的，但我再次处于一个我想与不是分支父/子分支的分支合并的场景中。
@rchen 在这种情况下，解决方案可能是预防。您认为您可以对组织中的分支实施更严格的控制吗？

【解决方案2】：

我认为你应该看看 VS ALM Rangers 整理的分支指南。

http://tfsbranchingguideiii.codeplex.com/

这应该可以回答您的所有问题。您正在查看一个相当高级的分支计划。我的博客上也有一些很好的实用指南。我知道我说的是 Scrum 团队，但它基本上是基于指南的功能分支。

http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx

如果有机会请投票在新的“Visual Studio ALM” StackExchange 和我们一样在 Area51 试图建立一个专门的地方回答这些问题 Visual Studio ALM MVP 和 Visual Studio ALM Rangers 随时为您解答你的问题。

http://area51.stackexchange.com/proposals/15894/visual-studio-alm

【讨论】：

您的博客看起来很熟悉。我相信当我开始研究这个时，我的搜索就遇到了它。我的问题是，所有东西可能不会同时得到提升。显然我理解这样做的好处，但它不适用于我的情况。这就是所有这些分支策略对我不利的地方。
:) 使用 TFS 2010，您可以看到能够通过分支提升变更集，从而仅提升您想要的代码。它可以在 2008 年完成，并在分支指南中有详细说明。
最后一个是“该提案已被删除”的死链接。

【解决方案3】：

[我知道这个问题很老，但这可能会帮助遇到这个问题的其他人]

大多数“每个功能分支”团队使用一个“主”分支并脱离每个环境分支的方法。可以通过在 MAIN 分支上明确标记每个环境版本来处理环境版本。

QA 版本是将所有被认为经过全面测试并准备好进行 QA 的功能/问题分支合并到 MAIN 中的结果。当发现错误时，新的错误分支从 MAIN 分支出来，这些分支被修复并合并回 MAIN。当所有 QA 版本都已准备好投入生产时，就会从 MAIN 构建一个 PROD 版本。简而言之，MAIN 是代码的唯一来源。

如果您需要提前工作，可以使用集成测试分支 (TEST) 来确定哪些功能已“准备好生产”，但应根据具体情况将功能/问题分支合并到 MAIN，而不是从 TEST 分支批量下载。

可以从 PROD 标签分支修补程序，然后对其进行修复、测试并合并回 MAIN 以获得新的 PROD 版本。

我将向您推荐有关 Branch per Feature 的精彩视频。它专注于 GIT，但策略不依赖于 GIT，并且可以在 TFS SCC 上同样有效地使用：https://youtu.be/9SZ7kSQ2424

【讨论】：