Git 分支策略与测试/QA 流程相结合 [英] Git branching strategy integated with testing/QA process

问题描述

我们的开发团队一直在使用 GitFlow 分支策略和太棒了！

Our development team has been using the GitFlow branching strategy and it has been great !

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

Recently we recruited a couple testers to improve our software quality. The idea is that every feature should be tested/QA by a tester.

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

In the past, developers work on features on separate feature branches and merge them back to the develop branch when done. The developer will test his work himself on that feature branch. Now with testers, we start asking this Question

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

On which branch should the tester test new features ?

显然，有两种选择:

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

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

Initially, we believed this is the sure way to go because:

• 自开发开始以来，该功能与合并到 develop 分支的所有其他功能一起进行了测试.
• 可以更早地检测到任何冲突
• 这使测试人员的工作变得轻松，他始终只处理一个分支(develop).他不需要问开发者哪个分支对应哪个特性(特性分支是由相关开发者独家自由管理的个人分支)

• The feature is tested with all other features merged to the develop branch since it's development started.
• Any conflicts can be detected earlier than later
• It makes the tester's job easy, he is only dealing with one branch (develop) at all time. He doesn't need to ask the developer about which branch is for which feature ( feature branches are personal branches managed exclusively and freely by relevant developers )

最大的问题是:

• develop 分支被错误污染.

当测试人员发现错误或冲突时，他将它们报告给开发人员，开发人员在开发分支上修复问题(功能分支一旦合并就被放弃)，之后可能需要更多的修复.如果可能，多个子序列提交或合并(如果从 develop 分支重新创建一个分支以修复错误)会使从 develop 分支回滚功能变得非常困难.develop 分支在不同时间合并并修复了多个功能.当我们想要创建一个仅包含 develop 分支

When the tester finds bugs or conflicts, he reports them back to the developer, who fixes the issue on the develop branch (the feature branch were abandoned once merged ), and there could be more fixes required afterward. Multiple subsequence commits or merges (if a branch is recreated off develop branch again for fixing the bugs) makes rolling back the feature from the develop branch very difficult if possible. There are multiple features merging to and being fixed on the develop branch at different times. This creates a big issue when we want to create a release with just some of the features in the develop branch

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

So we thought again and decided we should test features on the feature branches. Before we test, we merge the changes from the develop branch to the feature branch ( catch up with the develop branch ). This is good:

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

但是，有一些缺点

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

• The tester has to do the merging of the code, and if there's any conflict (very likely), he has to ask the developer for help. Our testers specialize in test and are not capable of coding.
• a feature could be tested without the existence of another new feature. e.g. Feature A and B are both under test at the same time, the two features are unaware of each other because neither of them has been merged to the develop branch. These means you will have to test against the develop branch again when both of the features are merged to the develop branch anyway. And you have to remember to test this in the future.
• If Feature A and B are both tested and approved, but when merged a conflict is identified, both of the developers for both features believe it is not his own fault/job because his feature branch past the test. There is an extra overhead in communication, and sometimes whoever resolving the conflict is frustrated.

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

Above is our story. With limited resource, I would like to avoid testing everything everywhere. We are still looking for a better way to cope with this. I would love to hear how other teams handle this kind of situations.

推荐答案

我们的做法如下:

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

We test on the feature branches after we merge the latest develop branch code on them. The main reason is that we do not want to "pollute" the develop branch code before a feature is accepted. In case a feature would not be accepted after testing but we would like to release other features already merged on develop that would be hell. Develop is a branch from which a release is made and thus should better be in a releasable state. The long version is that we test in many phases. More analytically:

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

您如何看待这种方法?

这篇关于Git 分支策略与测试/QA 流程相结合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！