结合测试/ QA流程的Git分支策略

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

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

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

测试人员应在哪个分支上测试新功能？

显然，有两种选择：

• 在单个要素分支上
• 在develop树枝上

测试开发分支

最初，我们认为这是肯定的方法，因为：

• develop自从开发开始，就将该功能与合并到分支的所有其他功能进行了测试。
• 可以早于任何时间检测到任何冲突
• 这使测试人员的工作变得容易，他始终只处理一个分支（develop）。他不需要询问开发人员哪个功能是哪个分支（功能分支是由相关开发者专有和自由管理的个人分支）。

最大的问题是：

• 该develop分支被错误污染。

  当测试人员发现错误或冲突时，他会将错误报告给开发人员，由开发人员在开发分支上修复该问题（功能分支在合并后就被废弃了），此后可能需要进行更多修复。多个子序列的提交或合并（如果develop再次从分支上重新创建分支以修复错误），develop如果可能的话，使从分支回滚功能非常困难。develop在不同时间有多个功能合并并固定在分支上。当我们要创建仅包含develop分支中某些功能的发行版时，这会带来一个大问题

在功能分支上测试

因此，我们再次考虑并决定应该在功能分支上测试功能。在测试之前，我们将develop分支之间的更改合并到功能分支（赶上develop分支）。这很好：

• 您仍然可以与主流的其他功能一起测试该功能
• 进一步的开发（例如，错误修复，解决冲突）不会污染develop分支。
• 您可以轻松地决定不发布该功能，除非对其进行了全面测试和批准；

但是，有一些缺点

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

以上是我们的故事。在资源有限的情况下，我想避免在任何地方进行所有测试。我们仍在寻找更好的方法来解决这一问题。我很想听听其他团队如何处理这种情况。

我们的方法如下：

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

1. 开发人员为每个新功能创建一个功能分支。
2. 功能分支（每次提交）（自动）部署在我们的TEST环境中，供开发人员进行测试。
3. 当开发人员完成部署并准备好测试功能时，他会在功能分支上合并开发分支，然后部署包含TEST上所有最新开发更改的功能分支。
4. 测试人员在TEST上进行测试。完成后，他“接受”故事并合并开发中的要素分支。由于开发人员以前已经合并了功能的开发分支，因此通常不会发生太多冲突。但是，如果是这种情况，开发人员可以提供帮助。这是一个棘手的步骤，我认为避免这种情况的最佳方法是保持功能尽可能小/特定。最终必须以一种或另一种方式合并不同的功能。当然，团队的规模在这一步骤的复杂性中起作用。
5. 开发分支也（自动）部署在TEST上。我们有一个政策，即使功能分支的构建可能会失败，而开发分支也绝不会失败。
6. 一旦我们冻结了功能，就可以从development创建一个发行版。它会自动部署在STAGING上。在生产部署之前，在此处进行了广泛的端到端测试。（好的，也许我有点夸张，它们不是很广泛，但我认为应该是）。理想情况下，beta测试人员/同事（即真正的用户）应该在那里进行测试。

您如何看待这种方法？

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

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

使开发人员在的基础上对其feature分支进行重新部署devel，然后将该feature分支推送（开发人员已确认该分支已在最新devel分支状态之上进行编译和工作）。
这允许：

• 功能分支上的非常简单的集成（简单的快速合并）。
• 或者，如下面的评论中Aspasia所建议的，请求请求（GitHub）或合并请求（GitLab）：维护者在功能PR / MR分支和之间进行合并，但前提是GitHub / GitLab未检测到冲突。develop

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

• 修正错误
• 在最近获取的开发分支的基础上重新建立基础（同样，请确保他/她的代码与其他经过验证的功能集成在一起）
• 推动feature分支。

总体思路：确保合并/集成部分由开发人员完成，将测试留给质量检查人员进行。

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

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

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

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

我们使用所谓的“金”，“银”和“青铜”。这可以称为prod，staging和qa。

我来称它为熔炉模型。它对我们而言效果很好，因为在业务方面我们对质量保证非常有需求，因为相对于技术而言，要求可能很难理解。

当错误或功能可以进行测试时，它会变成“古铜色”。这将触发jenkins构建，从而将代码推送到预构建环境。我们的测试人员（不是超级技术人员）只是点击了一个链接，并不关心源代码控制。这个构建也运行测试等。如果测试（单元，集成，硒）失败了，我们实际上是在这个构建上来回推送代码到测试\ qa环境。如果您在单独的系统上进行测试（我们称其为Lead），则可以防止所做的更改被推送到您的qa环境中。

最初的担心是我们在这些功能之间会有很多冲突。确实发生了功能X使功能Y看起来好像坏了的情况，但这种情况很少出现，并且确实有帮助。它有助于在似乎变化的上下文之外进行广泛的测试。很多时候，您会发现您的更改如何影响并行开发。

功能通过质量检查后，我们会将其移至“银色”或暂存状态。运行了构建，并再次运行了测试。每周，我们将这些更改推送到“金”或产品树中，然后将其部署到我们的生产系统中。

开发人员从金树开始进行更改。从技术上讲，您可以从暂存开始，因为这些很快就会增加。

紧急修复程序直接放入金树中。如果更改很简单且难以进行质量检查，则可以直接进入白银，它将进入测试树。

发布之后，我们将黄金（产品）的更改推向古铜色（测试），以使所有内容保持同步。

在推送到暂存文件夹之前，可能需要重新设置基础。我们发现不时清除测试树可以使其保持干净。有时功能会在测试树中被放弃，特别是如果开发人员离开。

对于大型的多开发人员功能，我们创建了一个单独的共享存储库，但是准备就绪后，将其合并到测试树中。事情确实容易从QA反弹，因此保持变更集隔离是很重要的，这样您可以添加并合并/压缩到暂存树中。

“烘焙”也是一个不错的副作用。如果您有一些根本性的改变，您可以坐一会儿，这是一个不错的地方。

另外请记住，我们不维护以前的版本。当前版本始终是唯一的版本。即使这样，您也可能拥有一棵主烘烤树，您的测试人员或社区可以在上面观察各种贡献者之间的相互作用。

我不会单靠手动测试。我将使用Jenkins自动执行每个功能分支的测试。我设置了一个VMWare实验室，以针对所有浏览器在Linux和Windows上运行Jenkins测试。这确实是一个很棒的跨浏览器，跨平台测试解决方案。我使用Selenium Webdriver测试功能/集成。我的硒测试在Rspec下运行。我专门编写了它们，以供Windows上的jRuby加载。我在Rspec下运行传统的单元测试，在Jasmine下运行Javascript测试。我使用Phantom JS设置了无头测试。

在我们公司中，我们不能使用敏捷开发，而对于每项业务变更都需要批准，这会引起很多问题。

我们与GIT合作的方法是这样的；

我们在公司中实施了“ Git Flow”。我们使用的是JIRA，只有批准的JIRA门票才能生产。为了获得测试批准，我们使用单独的Test-Branch淘汰了它。

处理JIRA票证的步骤如下：

1. 从Develop-Branch创建一个新的分支
2. 在功能分支上更改代码吗
3. 从功能中拉出更改到Test / QA分支
4. 在业务批准后，我们​​将更改从功能分支转移到开发中
5. 开发经常在发行版中进行，然后最终成为主分支

将每个请求拆分为一个自己的功能可确保只有批准的更改才能投入生产。

完整的过程如下所示：