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

Question

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

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

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

  

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

显然，有两种选择：

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

测试开发分支

最初，我们相信这是可靠的方法，因为：

• 该功能已经过测试，其中所有其他功能已合并到develop分支，因为它已开始开发。
• 任何冲突都可以在以后检测到
• 它使测试人员的工作变得轻松，他只是在处理一个分支（develop）。他不需要向开发人员询问哪个分支是针对哪个功能（功能分支是由相关开发人员独立管理的个人分支机构）

最大的问题是：

• develop分支受到bug的污染。

  当测试人员发现错误或冲突时，他会将它们报告给开发人员，后者会在开发分支上修复问题（功能分支在合并后被放弃），之后可能需要更多修复。多个子序列提交或合并（如果再次在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下面in the comments的建议，pull request (GitHub)或merge request (GitLab)：维护者在功能PR / MR分支和{{1}之间进行合并}，但只有在没有冲突的情况下才能被GitHub / GitLab检测到。

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

• 修复错误
• 在最近获取的开发分支之上进行rebase（再次，确保他/她的代码与其他经过验证的功能集成）
• 推送develop分支。

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

Answer 3

最好的方法是continuous integration，其中一般的想法是尽可能频繁地将功能分支合并到开发人员分支中。这减少了合并痛苦的开销。

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

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

有关详细信息，请查看此link。

Answer 4

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

我来称之为熔炉模型。它对我们很有用，因为我们对业务方面的QA有很大的需求，因为要求与技术难以理解。

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

最初的担心是我们在这些功能之间会有很多冲突。它确实发生了特征X使它看起来像Y正在打破，但它很少，实际上有帮助。它有助于在变化的背景之外进行大量测试。幸运的是，很多时候你会发现你的变化如何影响并行发展。

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

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

紧急修复工具直接进入金树。如果变更很简单且难以进行QA，那么它可以直接进入白银，它将进入测试树。

在我们发布之后，我们将黄金（prod）的变化推送到青铜（测试），以保持一切同步。

您可能希望在推入暂存文件夹之前进行重新定位。我们发现不时清除测试树使其保持清洁。有时功能会在测试树中被遗弃，尤其是在开发人员离开时。

对于大型多开发人员功能，我们创建一个单独的共享仓库，但在我们准备就绪时将其合并到测试树中。事情会从质量保证中反弹，因此保持您的变更集是独立的非常重要，这样您就可以添加，然后合并/压缩到您的登台树。

“烘焙”也是一个很好的副作用。如果你有一些根本性的改变，你想让它坐一会儿有一个不错的地方。

另请注意，我们不保留过去的版本。当前版本始终是唯一的版本。即便如此，你可能还有一个大师烘焙树，你的测试人员或社区可以在这里看到各种贡献者之间的互动。

Answer 5

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

Answer 6

在我们公司中，我们不能使用敏捷开发，而对于每项业务变更都需要批准，这会引起很多问题。

我们与GIT合作的方法是这样的

我们在公司中实施了“ Git Flow”。我们使用的是JIRA，只有批准的JIRA门票才能生产。为了获得测试批准，我们使用单独的Test-Branch淘汰了它。

处理JIRA票证的步骤是：

1. 通过Develop-Branch创建新分支
2. 在功能分支上更改代码
3. 从地图项中拉出更改到Test / QA分支
4. 获得业务批准后，我们​​将功能分支中的更改引入到开发中
5. 开发过程经常在发行版本中发布，然后最终成为master分支

将每个请求拆分为自己的功能可确保只有批准的更改才能投入生产。

完整的过程如下所示：