集成测试/QA流程的Git分支策略

Question

我们的开发团队一直在使用GitFlow分支策略，它很棒！

最近我们招募了一些测试人员来提高我们的软件质量。这个想法是，每个特性都应该由测试人员进行测试/QA。

过去，开发人员在单独的功能分支上处理功能，并在完成后将它们合并回开发分支。开发人员将在该功能分支上亲自测试其工作。现在有了测试人员，我们开始问这个问题

测试人员应该在哪个分支上测试新特性？

显然，有两种选择：

• 在单个功能分支上
• 在开发分支上

最初，我们认为这是必经之路，因为：

• 自开发开始以来，该功能已与所有其他功能合并到develop分支中进行测试
• 可以早于晚检测到任何冲突
• 这使得测试人员的工作变得简单，他在任何时候都只处理一个分支（开发）。他不需要询问开发人员哪个分支用于哪个功能（功能分支是由相关开发人员单独自由管理的个人分支）

最大的问题是：

>

develop分支被bug污染。

当测试人员发现错误或冲突时，他会将其报告给开发人员，开发人员在开发分支上修复问题（功能分支在合并后被放弃），之后可能需要更多修复。多个子序列提交或合并（如果在开发分支上重新创建分支以修复错误）使得尽可能从开发分支回滚功能变得非常困难。有多个功能在不同时间合并到开发分支并在其上得到修复。当我们想要创建一个仅包含开发分支中的一些功能的版本时，这会产生一个大问题

因此，我们再次考虑，决定在特性分支上测试特性。在测试之前，我们将从develop分支到feature分支的更改合并（赶上develop分支）。这很好：

• 您仍然可以使用主流中的其他功能测试该功能
• 进一步的开发（例如bug修复、解决冲突）不会污染开发分支
• 您可以很容易地决定不发布该功能，直到它被完全测试和批准

然而，也有一些缺点

• 测试人员必须进行代码的合并，如果有任何冲突（很可能），他必须向开发人员寻求帮助。我们的测试人员专门从事测试，不会编码。
• 一个特性可以在不存在另一个新特性的情况下进行测试。例如，特性A和B都在同时测试中，这两个特性彼此不知道，因为它们都没有合并到Development分支。这意味着当两个特性都合并到开发分支时，您必须再次针对Development分支进行测试。你必须记住将来要测试这个。
• 如果功能A和功能B都经过测试和批准，但是当合并时发现了冲突，两个功能的开发人员都认为这不是他自己的错/工作，因为他的功能分支通过了测试。沟通中有额外的开销，有时解决冲突的人会感到沮丧。

以上是我们的故事。由于资源有限，我希望避免到处测试所有东西。我们仍在寻找更好的方法来应对这种情况。我很想听听其他团队如何处理这种情况。

Answer 1

最好的方法是持续集成，一般的想法是尽可能频繁地将功能分支合并到开发人员分支中。这减少了合并痛苦的开销。

尽可能依赖自动化测试，并在Jenkins之前通过单元测试自动启动构建。让开发人员完成将他们的更改合并到主分支的所有工作，并为他们的所有代码提供单元测试。

测试人员/QA可以参与代码审查，检查单元测试，并编写自动集成测试，以便在功能完成时添加到回归套件中。

有关更多信息，请查看此链接。

Answer 2

在测试之前，我们将开发分支的更改合并到功能分支

不，不要，尤其是如果“我们”是QA测试人员。合并将涉及解决潜在的冲突，这最好由开发人员（他们知道自己的代码）来完成，而不是由QA测试人员（他们应该尽快进行测试）来完成。

让开发人员在 devel 之上对他/她的功能分支进行重基，并推送该功能分支（开发人员已验证该分支分支已在最新的 devel 分支状态之上编译和工作）。
这允许：

< li >功能分支上非常简单的集成(简单的快速前进合并)。 < li >或者，如Aspasia在下面的评论中所建议的，pull请求(GitHub)或merge请求(GitLab):维护人员在特性PR/MR分支和< code>develop之间进行合并，但前提是GitHub/GitLab没有检测到冲突。

每次测试人员检测到错误时，他/她都会将其报告给开发人员并删除当前的功能分支。
开发人员可以：

• 修复错误
• 在最近获取的开发分支之上重新定位（再次，确保他/她的代码与其他经过验证的功能集成）
• 推送功能分支。

总体思路：确保合并/集成部分由开发人员完成，将测试留给QA。

Answer 3

我们的做法如下:

在我们合并最新的开发分支代码后，我们在功能分支上进行测试。主要原因是我们不想在一个功能被接受之前“污染”开发分支代码。如果一个功能在测试后不被接受，但我们想发布已经在开发中合并的其他功能，那将是地狱。开发是一个发布的分支，因此最好处于可发布状态。长版本是我们分许多阶段进行测试。更具分析性：

< li >开发人员为每个新功能创建一个功能分支。 < li >特性分支(自动)部署在我们的测试环境中，每次提交都由开发人员进行测试。 < li >当开发人员完成部署并且功能准备好进行测试时，他将开发分支合并到功能分支上，并部署包含所有最新测试开发更改的功能分支。 < li >测试仪对测试进行测试。当他完成后，他“接受”了这个故事，并在develop上合并了特性分支。由于开发人员之前已经合并了特性上的开发分支，我们通常不希望有太多的冲突。然而，如果是这种情况，开发者可以提供帮助。这是一个棘手的步骤，我认为避免它的最好方法是让特性尽可能的小/具体。不同的功能最终必须以某种方式合并。当然，团队的规模对这一步的复杂性有一定影响。 < li >开发分支也在测试时(自动)部署。我们有一个策略，即使特性分支构建可能失败，开发分支也不应该失败。 < li >一旦我们达到功能冻结，我们将从开发中创建一个版本。这是在暂存时自动部署的。在生产部署之前，会在那里进行大量的端到端测试。(好吧，也许我夸大了一点，他们不是很广泛，但我认为他们应该是)。理想情况下，beta测试人员/同事，即真实用户应该在那里进行测试。

你觉得这种方法怎么样？