集成测试/QA 过程的 Git 分支策略

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

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

在过去，开发人员在单独的特性分支上处理特性，并在完成后将它们合并回 develop分支。开发人员将自己在 feature分支上测试他的工作。现在，对于测试人员，我们开始提出这个问题

测试人员应该在哪个分支上测试新特性？

显然，有两种选择:

  • 在个人特写部分
  • 在 develop分行

开发分公司测试

最初，我们认为这是必然的选择，因为:

  • 自从开发工作开始以来，该特性已经通过与 develop分支合并的所有其他特性进行了测试。
  • 任何冲突都可以早于后来检测到
  • 这使得测试人员的工作变得容易，他在任何时候都只处理一个分支(develop)。他不需要询问开发人员哪个分支用于哪个特性(特性分支是由相关开发人员独家自由管理的个人分支)

最大的问题是:

  • develop分支被虫子污染了。

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

特征分支测试

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

  • 您仍然可以使用主流的其他特性来测试该特性
  • 进一步的开发(例如修复 bug、解决冲突)不会污染 develop分支;
  • 您可以很容易地决定在完全测试和批准之前不发布该特性;

然而，也有一些缺点

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

以上就是我们的故事。由于资源有限，我希望避免在任何地方测试任何东西。我们仍在寻找更好的方法来应对这一问题。我很想听听其他球队是如何处理这种情况的。

50881 次浏览
小开

我不会仅仅依靠手工测试。我将与 Jenkins 一起自动化每个特性分支的测试。我建立了一个 VMWare 实验室，在 Linux 和 Windows 上为所有浏览器运行 Jenkins 测试。它真的是一个非常棒的跨浏览器跨平台测试解决方案。我使用 Selenium WebDriver 测试功能/集成。我的硒测试在 Rspec 下运行。我特意写了这些文件，让它们在 Windows 上由 jRuby 加载。我在 Rspec 下运行传统的单元测试，在 Jasmine 下运行 Javascript 测试。我用 Phantom JS 设置了无头测试。

小开

在测试之前，我们合并从开发分支到特性分支的更改

没有。不要，特别是如果“我们”是质量保证测试人员。合并将涉及到解决潜在的冲突，这最好由开发人员(他们知道自己的代码)来完成，而不是 QA 测试人员(他们应该尽快进行测试)。

让开发人员执行 他/她的 ABC0分行在 devel之上的基础和 推动 feature分支(已由开发人员验证为在最新的 devel分支状态之上编译和工作)。
考虑到:

每次测试人员检测到 bug，他/她都会向开发人员和 删除报告当前的特性分支。
发展商可:

  • 修好漏洞
  • Rebase 位于最近获取的开发分支之上(同样，为了确保他/她的代码与其他经过验证的特性集成在一起)
  • 推动 feature分支。

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

小开

最好的方法是 连续整合，其总体思想是尽可能频繁地将特性分支合并到开发人员分支中。这减少了合并阵痛的开销。

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

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

欲了解更多信息，请查看此 链接。

小开
最佳答案

我们的做法如下:

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

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

你觉得这个方法怎么样？

小开

我们使用我们所说的“金”、“银”和“铜”，这可以被称为戳、分段和 qa。

我称之为大熔炉模型。它很适合我们，因为我们在业务方面对 QA 有巨大的需求，因为与技术相比，需求可能很难理解。

当一个 bug 或特性准备好进行测试时，它就变成了“青铜”。这将触发将代码推送到预构建环境的 Jenkins 构建。我们的测试人员(顺便说一句，不是超级技术人员)只是点击了一个链接，并不关心源代码控制。这个版本也运行测试等等。如果测试(单元、集成、硒)失败，我们将代码推送到测试 qa 环境。如果您在一个单独的系统上进行测试(我们称之为 lead) ，那么您可以防止将更改推送到您的 qa 环境中。

最初的担心是这些特性之间会有很多冲突。这种情况确实发生了，因为特性 X 让它看起来像特性 Y 正在破坏，但是这种情况并不常见，而且确实有所帮助。它有助于在看起来是变更的上下文之外获得广泛的测试。很多时候，幸运的是你会发现你的改变是如何影响并行开发的。

一旦某个特性通过了 QA，我们就把它移动到“白银”或者阶段。运行生成并再次运行测试。每周我们都会将这些变更推送到我们的“黄金”或者戳树中，然后将它们部署到我们的生产系统中。

开发人员从黄金树开始他们的变化。技术上来说，你可以从舞台开始，因为那些很快就会上升。

紧急补救措施被直接投入到黄金树中。如果一个变更对于 QA 来说是简单和困难的，那么它可以直接进入到测试树中去。

在我们发布之后，我们将金(点)的变化推到青铜(测试) ，只是为了保持一切同步。

您可能希望在推送到准备文件夹之前进行重新基础设置。我们发现，不时地清除测试树可以保持它的清洁。有时候特性会被放弃在测试树中，特别是当开发人员离开的时候。

对于大型的多开发者特性，我们创建一个单独的共享回购，但是当我们准备好的时候，将它合并到测试树中。事情往往从 QA 反弹，所以重要的是保持您的变更集隔离，以便您可以添加，然后合并/压缩到您的登台树。

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

还要记住，我们不维护过去的版本。当前版本总是唯一的版本。即便如此，你也可能有一个主烘焙树，在那里你的测试人员或社区可以敲击看到各种贡献者的东西如何交互。

小开

在我们的公司里，我们不能使用敏捷开发，而且每次业务变更都需要得到批准，这会导致很多问题。

我们使用 GIT 的方法是这样的;

我们已经在公司实现了“ Git Flow”。我们使用 JIRA 和只批准 JIRA 票应该去生产。为了获得测试批准，我们创建了一个独立的 Test-Branch 来扩展它。

处理 JIRA 票的步骤如下:

  1. 从 Development-Branch 创建一个新的分支
  2. 在 Feature-Branch 上进行代码更改
  3. 从特征中抽取对测试/质量保证分支的更改
  4. 经过业务批准后，我们将变更从特性分支拉入开发
  5. 开发经常在一个版本中进行，然后最终掌握分支

将每个请求分割到一个自己的特性中可以确保，只有经过批准的更改才能投入生产。

整个过程如下: enter image description here


提交答案