Git分支策略与测试/ QA流程集成在一起

Question

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

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

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

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

显然,有两种选择:

• 在个别功能分支上
• 在develop树枝上

测试开发分支

最初,我们相信这是肯定的方法,因为:

• develop自开发开始以来,该功能已与所有其他功能合并到分支进行测试.
• 任何冲突都可以在以后检测到
• 它使测试人员的工作变得轻松,他只是在处理一个分支(develop).他不需要向开发人员询问哪个分支是针对哪个功能的(功能分支是由相关开发人员独立管理的个人分支)

最大的问题是:

• 该develop分支被污染与臭虫.

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

功能分支测试

所以我们再次思考并决定我们应该在功能分支上测试功能.在我们测试之前,我们将更改从develop分支合并到功能分支(赶上develop分支).这很好:

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

但是,存在一些缺点

• 测试人员必须合并代码,如果有任何冲突(非常可能),他必须向开发人员寻求帮助.我们的测试人员专门从事测试,无法编码.
• 可以在不存在其他新功能的情况下测试功能.例如,特征A和B同时都在测试中,这两个特征彼此不知道,因为它们都没有合并到develop分支.这意味着,develop无论如何,当两个功能都合并到开发分支时,您将不得不再次测试分支.你必须记得将来测试这个.
• 如果功能A和B都经过测试和批准,但在合并时发现冲突,两个功能的开发人员都认为这不是他自己的错误/工作,因为他的功能分支超过了测试.沟通会产生额外的开销,有时解决冲突的人会感到沮丧.

---

以上是我们的故事.由于资源有限,我想避免在所有地方进行测试.我们仍在寻找更好的方法来应对这种情况.我很想知道其他团队如何应对这种情况.

Answer 1

我们这样做的方式如下:

在我们合并最新的开发分支代码之后,我们在功能分支上进行测试.主要原因是我们不希望在接受功能之前"污染"开发分支代码.如果测试后不接受某个功能,但我们想发布已经合并开发的其他功能,这将是地狱.Develop是一个发布版本的分支,因此最好处于可释放状态.长版本是我们在很多阶段进行测试的.更具分析性:

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

您如何看待这种方法？

Answer 2

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

不,不要,尤其是'我们'是QA测试员.合并将涉及解决潜在的冲突,最好由开发人员(他们知道他们的代码)完成,而不是由QA测试人员(他们应该尽快进行测试).

让开发人员在他/她的feature分支之上devel做一个rebase,并推送该feature分支(已经由开发人员验证为编译并在最近的devel分支状态之上工作).
这允许:

• 在功能分支上进行非常简单的集成(简单的快进合并).
• 或者,如下面评论中的Aspasia所推荐的,拉取请求(GitHub)或合并请求(GitLab):维护者在功能PR/MR分支之间进行合并,但只有在GitHub/GitLab检测到不冲突的情况下才会合并.develop

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

• 修复bug
• 在最近获取的开发分支之上重新定义(再次,确保他/她的代码与其他经过验证的功能集成)
• 推动feature分支.

一般想法:确保合并/集成部分由开发人员完成,将测试留给QA.

Answer 3

最好的方法是持续集成,其中一般的想法是尽可能频繁地将特征分支合并到开发人员分支中.这减少了合并疼痛的开销.

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

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

有关更多信息,请查看此链接.

Answer 4

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

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

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

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

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

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

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

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

您可能需要在移入暂存文件夹之前进行变基。我们发现不时清除测试树可以使其保持干净。有时功能会在测试树中被放弃，尤其是在开发人员离开的情况下。

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

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

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