6
结合测试/ QA流程的Git分支策略
我们的开发团队一直在使用GitFlow分支策略,这非常棒! 最近,我们招募了一些测试人员来提高我们的软件质量。这个想法是每个功能都应该由测试人员进行测试/质量检查。 过去,开发人员在单独的要素分支上处理要素,并develop在完成后将其合并回分支。开发人员将自己在该feature分支上测试其工作。现在有了测试人员,我们开始问这个问题 测试人员应在哪个分支上测试新功能? 显然,有两种选择: 在单个要素分支上 在develop树枝上 测试开发分支 最初,我们认为这是肯定的方法,因为: develop自从开发开始,就将该功能与合并到分支的所有其他功能进行了测试。 可以早于任何时间检测到任何冲突 这使测试人员的工作变得容易,他始终只处理一个分支(develop)。他不需要询问开发人员哪个功能是哪个分支(功能分支是由相关开发者专有和自由管理的个人分支)。 最大的问题是: 该develop分支被错误污染。 当测试人员发现错误或冲突时,他会将错误报告给开发人员,由开发人员在开发分支上修复该问题(功能分支在合并后就被废弃了),此后可能需要进行更多修复。多个子序列的提交或合并(如果develop再次从分支上重新创建分支以修复错误),develop如果可能的话,使从分支回滚功能非常困难。develop在不同时间有多个功能合并并固定在分支上。当我们要创建仅包含develop分支中某些功能的发行版时,这会带来一个大问题 在功能分支上测试 因此,我们再次考虑并决定应该在功能分支上测试功能。在测试之前,我们将develop分支之间的更改合并到功能分支(赶上develop分支)。这很好: 您仍然可以与主流的其他功能一起测试该功能 进一步的开发(例如,错误修复,解决冲突)不会污染develop分支。 您可以轻松地决定不发布该功能,除非对其进行了全面测试和批准; 但是,有一些缺点 测试人员必须合并代码,如果有冲突(很有可能),他必须向开发人员寻求帮助。我们的测试人员专门从事测试,无法编码。 一个功能可以在不存在另一个新功能的情况下进行测试。例如,功能A和功能B都同时在测试中,由于这两个功能都没有合并到develop分支中,因此这两个功能互不了解。这意味着develop无论如何,当两个功能都合并到develop分支时,您将不得不再次对该分支进行测试。而且您必须记住将来要进行测试。 如果功能A和功能B均经过测试和批准,但在合并时发现冲突,则两个功能的开发人员都认为这不是他自己的错/工作,因为他的功能分支通过了测试。通信中存在额外的开销,有时解决冲突的人都会感到沮丧。 以上是我们的故事。在资源有限的情况下,我想避免在任何地方进行所有测试。我们仍在寻找更好的方法来解决这一问题。我很想听听其他团队如何处理这种情况。