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

Git branching strategy integated with testing/QA process

提问by David Lin

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

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

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

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

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

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

On which branch should the tester test new features ?

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

Obviously, there are two options:

显然，有两种选择：

• on the individual feature branch
• on the developbranch

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

Testing On Develop Branch

在 Develop 分支上测试

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

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

• The feature is tested with all other features merged to the developbranch 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)。他不需要问开发者哪个分支对应哪个特性（特性分支是由相关开发者独家自由管理的个人分支）

The biggest problems with this is:

最大的问题是：

• The developbranch is polluted with bugs.

  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 developbranch again for fixing the bugs) makes rolling back the feature from the developbranch very difficult if possible. There are multiple features merging to and being fixed on the developbranch at different times. This creates a big issue when we want to create a release with just some of the features in the developbranch

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

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

Testing On Feature Branch

在功能分支上测试

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

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

• You still test the feature with other features in the mainstream
• Further development ( e.g. bug fix, resolving conflict ) will not pollute the developbranch;
• You can easily decide not to release the feature until it is fully tested and approved;

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

However, there are some drawbacks

但是，也有一些缺点

• 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 developbranch. These means you will have to test against the developbranch 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.

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

---

---

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.

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

采纳答案by Aspasia

The way we do it is the following:

我们的做法如下：

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:

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

1. Developer creates a feature branch for every new feature.
2. The feature branch is (automatically) deployed on our TEST environment with every commit for the developer to test.
3. When the developer is done with deployment and the feature is ready to be tested he merges the develop branch on the feature branch and deploys the feature branch that contains all the latest develop changes on TEST.
4. The tester tests on TEST. When he is done he "accepts" the story and merges the feature branch on develop. Since the developer had previously merged the develop branch on feature we normally don't expect too many conflicts. However, if that's the case the developer can help. This is a tricky step, I think the best way to avoid it is to keep features as small/specific as possible. Different features have to be eventually merged, one way or another. Of course the size of the team plays a role on this step's complexity.
5. The develop branch is also (automatically) deployed on TEST. We have a policy that even though the features branch builds can fail the develop branch should never fail.
6. Once we have reached a feature freeze we create a release from develop. This is automatically deployed on STAGING. Extensive end to end tests take place on there before the production deployment. (ok maybe I exaggerate a bit they are not very extensive but I think they should be). Ideally beta testers/colleagues i.e. real users should test there.

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

What do you think of this approach?

您如何看待这种方法？

回答by VonC

Before test, we merge the changes from the develop branch to the feature branch

测试前，我们将develop分支的变更合并到feature分支

No. Don't, especially if 'we' is the QA tester. Merging would involve resolving potential conflicts, which is best done by developers (they know their code), and not by QA tester (who should proceed to test as quickly as possible).

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

Make the developer do a rebase of his/her featurebranch on top of devel, and push that featurebranch(which has been validated by the developer as compiling and working on top of the most recent develbranch state).
That allows for:

让开发人员在 之上重新创建他/她的feature分支devel，并推送该feature分支（已被开​​发人员验证为在最近的devel分支状态之上编译和工作）。
这允许：

• a very simple integration on the feature branch (trivial fast-forward merge).
• or, as recommended by Aspasiabelow in the comments, a pull request(GitHub)or merge request(GitLab): the maintainer does a merge between the feature PR/MR branch and develop, but only if not conflict are detected by GitHub/GitLab.

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

Each time the tester detects bug, he/she will report it to the developer and deletethe current feature branch.
The developer can:

测试人员每次检测到错误时，都会向开发人员报告并删除当前的功能分支。
开发者可以：

• fix the bug
• rebase on top of a recently fetched develop branch (again, to be sure that his/her code works in integration with other validated features)
• push the featurebranch.

• 修复错误
• 在最近获取的开发分支之上重新构建（再次确保他/她的代码与其他经过验证的功能集成在一起）
• 推动feature分支。

General idea: make sure the merge/integration part is done by the developer, leaving the testing to the QA.

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

回答by Johnny Z

The best approach is continuous integration, where the general idea is to merge the feature branches into the developer branch as frequently as possible. This reduces on the overhead of merging pains.

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

Rely on automated tests as much as possible, and have builds automatically kick off with unit tests by Jenkins. Have the developers do all the work with merging their changes into the main branch and provide unit tests for all their code.

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

The testers/QA can take participate in code reviews, check off on unit tests and write automated integration tests to be added to the regression suite as features are completed.

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

For more info check out this link.

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

回答by Eric Twilegar

We use what we call "gold", "silver", and "bronze". This could be called prod, staging, and qa.

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

I've come to call this the melting pot model. It works well for us because we have a huge need for QA in the business side of things since requirements can be hard to understand vs the technicals.

我来称其为熔炉模型。它对我们很有效，因为我们在业务方面非常需要 QA，因为与技术相比，需求可能难以理解。

When a bug or feature is ready for testing it goes into "bronze". This triggers a jenkins build that pushes the code to a pre-built environment. Our testers (not super techies by the way) just hit a link and don't care about the source control. This build also runs tests etc. We've gone back and forth on this build actually pushing the code to the testing\qa environment if the tests (unit, integration, selenium ) fail. If you test on a separate system ( we call it lead ) you can prevent the changes from being pushed to your qa environment.

当错误或功能准备好进行测试时，它会进入“青铜”状态。这会触发 jenkins 构建，将代码推送到预先构建的环境。我们的测试人员（顺便说一下，不是超级技术人员）只是点击了一个链接，并不关心源代码控制。此构建还运行测试等。如果测试（单元、集成、硒）失败，我们已经在此构建上来回实际将代码推送到 testing\qa 环境。如果您在单独的系统上进行测试（我们称之为 Lead ），您可以防止将更改推送到您的 qa 环境。

The initial fear was that we'd have lots of conflicts between this features. It does happen were feature X makes it seem like feature Y is breaking, but it is infrequent enough and actually helps. It helps get a wide swath of testing outside what seems is the context of the change. Many times by luck you will find out how your change effects parallel development.

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

Once a feature passes QA we move it into "silver" or staging. A build is ran and tests are run again. Weekly we push these changes to our "gold" or prod tree and then deploy them to our production system.

一旦功能通过 QA，我们就会将其移至“银色”或暂存阶段。运行构建并再次运行测试。每周我们将这些更改推送到我们的“黄金”或产品树，然后将它们部署到我们的生产系统。

Developers start their changes from the gold tree. Technically you could start from the staging since those will go up soon.

开发人员从金树开始他们的改变。从技术上讲，您可以从分期开始，因为这些很快就会上升。

Emergency fixes are plopped directly into the gold tree. If a change is simple and hard to QA it can go directly into silver which will find its way to the testing tree.

紧急修复直接放入金树。如果更改简单且难以进行 QA，则它可以直接进入银级，这将找到通往测试树的途径。

After our release we push the changes in gold(prod) to bronze(testing) just to keep everything in sync.

在我们发布后，我们将黄金（产品）的更改推送到青铜（测试），以保持一切同步。

You may want to rebase before pushing into your staging folder. We have found that purging the testing tree from time to time keeps it clean. There are times when features get abandoned in the testing tree especially if a developer leaves.

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

For large multi-developer features we create a separate shared repo, but merge it into the testing tree the same when we are all ready. Things do to tend bounce from QA so it is important to keep your changesets isolated so you can add on and then merge/squash into your staging tree.

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

"Baking" is also a nice side effect. If you have some fundamental change you want to let sit for a while there is a nice place for it.

“烘焙”也是一个不错的副作用。如果您有一些根本性的变化，您想坐一会儿，那么这里有一个不错的地方。

Also keep in mind we don't maintain past releases. The current version is always the only version. Even so you could probably have a master baking tree where your testers or community can bang on see how various contributors stuff interact.

还要记住，我们不维护过去的版本。当前版本始终是唯一的版本。即便如此，您也可能拥有一个主烘焙树，您的测试人员或社区可以在其中查看各种贡献者的内容如何交互。

回答by Natus Drew

I would not rely on manual testing alone. I would automate the testing of each feature branch with Jenkins. I setup a VMWare lab to run Jenkins tests on Linux and Windows for all browsers. It's truly an awesome cross browser, cross platform testing solution. I test functional/integration with Selenium Webdriver. My selenium tests run under Rspec. And I wrote them specially to be loaded by jRuby on Windows. I run traditional unit tests under Rspec and Javascript tests under Jasmine. I setup headless testing with Phantom JS.

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