Git分支策略与测试/质量保证过程相结合

 

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

最近我们招募了几个测试人员来提高我们的软件质量。 这个想法是每个功能都应该由测试人员测试/ QA。

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

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

显然，有两种选择：

  • 在个人功能分支上
  • 在develop分支上

    • 在开发分支上测试

    最初，我们相信这是一条肯定的路，因为：

  • 自开发开始以来，该功能将与所有其他功能合并到develop分支中进行测试。
  • 任何冲突都可以早于以后检测到
  • 它使得测试人员的工作变得简单，他只是一直在处理一个分支（ develop ）。 他无需向开发人员询问哪个分支是哪个功能（功能分支是由相关开发人员完全自由管理的个人分支）

    • 最大的问题是：

  • develop分支受到错误污染。

    当测试人员发现错误或冲突时，他会将其报告给开发人员，后者会在开发分支上解决问题（功能分支在合并后会被放弃），并且之后可能会需要更多修复程序。 多个子序列提交或合并（如果重新develop分支以重新develop分支以修复缺陷）使得从develop分支回滚特征非常困难（如果可能的话）。 在develop分支上有不同的时间合并和固定的多种功能。 当我们想通过develop分支中的一些功能创建一个版本时，这会造成很大的问题

    • 在功能分支上测试

    所以我们再次考虑，并决定我们应该测试功能分支上的功能。 在我们测试之前，我们将develop分支的变化合并到功能分支（赶上develop分支）。 这很好：

  • 您仍然使用主流中的其他功能测试该功能
  • 进一步的开发（例如错误修复，解决冲突）不会污染develop分支;
  • 在完全测试和批准之前，您可以轻松决定不发布该功能;

    • 但是，有一些缺点

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

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

    我们这样做的方式如下：

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

  • 开发人员为每个新功能创建一个功能分支。
  • 功能分支（自动）部署在我们的测试环境中，每次提交开发人员进行测试。
  • 当开发人员完成部署并且该功能已准备好进行测试时，他会合并功能分支上的开发分支，并部署包含TEST上所有最新开发更改的功能分支。
  • 测试人员在TEST上进行测试。 当他完成后，他“接受”了这个故事，并将这个功能分支合并到了开发中。 由于开发人员之前已经将开发分支合并到了功能上，所以我们通常不会指望出现太多冲突。 但是，如果是这种情况，开发人员可以提供帮助。 这是一个棘手的步骤，我认为避免它的最好方法是尽可能保持特性尽可能小/特定。 不同的特征必须最终以某种方式合并。 当然，团队的规模在这一步的复杂性上扮演着重要角色。
  • 开发分支也（自动）部署在TEST上。 我们有一个策略，即使功能分支构建可能会失败，开发分支不应该失败。
  • 一旦我们达到了功能冻结，我们就会从开发中创建一个版本。 这在STAGING上自动部署。 在生产部署之前进行广泛的端到端测试。 （好吧，也许我夸大了一点，他们不是很广泛，但我认为他们应该是）。 理想的beta测试者/同事，即真正的用户应该在那里测试。

    • 你对这种方法有什么看法？

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

    不，不，特别是如果'我们'是质量保证测试员。 合并将涉及解决潜在的冲突，最好由开发人员（他们知道他们的代码）完成，而不是由QA测试人员（应该尽快进行测试）完成。

    让开发商做他/她的底垫feature之上分支devel ，并推送这个feature分支 （已被开发验证为编制和最近的顶部工作devel分支状态）。
    这允许：

  • 一个非常简单的功能分支集成（简单的快进合并）。
  • 或者按照Aspasia下面在注释中推荐的方式， 请求 （GitHub）或合并请求 （GitLab）：维护者在特性PR / MR分支和develop之间进行合并，但只有在GitHub / GitLab检测不到冲突时。

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

  • 修复错误
  • 在最近获取的开发分支之上重新绑定（同样，要确保他/她的代码与其他已验证的功能集成在一起）
  • 推feature分支。

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

    最好的方法是持续集成，其中总体思路是尽可能经常地将特征分支合并到开发者分支中。 这减少了合并痛苦的开销。

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

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

    欲了解更多信息，请查看此链接。

    链接地址: http://www.djcxy.com/p/48939.html

    上一篇: Git branching strategy integated with testing/QA process

    下一篇: Git: getting changes from another branch