通过多个 E2E 测试优化 CI/CD 管道速度并降低单一存储库中的故障率

Question

背景：

我们管理一个单一存储库，多个团队在其中贡献代码。为了确保提交不会破坏其他团队的功能，我们采用了单元测试和 E2E 测试（在 TestCafe 中编写）的组合，其中 TypeScript 是我们的主要语言。每当有人提交 MR/PR 时，就会触发 CI/CD 管道，它包括各种步骤，例如：

1. 对 MR 头衔的基本检查和简单的健全性检查。

2. 运行构建作业。

3. 执行所有E2E和单元测试用例。

在我们的 E2E 测试中，我们验证端到端流程，涵盖诸如通过测试环境 API 创建用户、登录、以编程方式执行多个步骤（最终用户执行的操作）等任务，以及彻底测试一切是否正常美好的。 （注意 - 每一步都是通过 UI 完成的，我们不直接点击 BE）。

我们面临的问题：

我们目前面临的挑战是 MR/PR 准备好合并所需的时间。由于同时运行大约 7-8 个 E2E 测试用例（平均而言，测试数量可能会根据任何 MR 接触的文件而变化），管道持续时间会延长。管道中的任何测试失败都需要额外的提交，从而需要更多的等待时间。

此外，多个团队执行负载测试会导致测试用例失败，因为它破坏了我们的测试环境 API，阻碍了跨不同团队的更改部署。

这不仅会消耗大量时间，还会扰乱项目时间表并浪费开发人员的时间。

（注意 - 我们在测试环境 API 上进行整个测试）

到目前为止我们已经尝试过：

在努力解决该问题的过程中，我们尝试了各种策略，例如，

1. 我们尝试通过在不同的 AWS 实例上同时执行所有 7-8 个测试来同时运行测试。

2. 此外，我们在管道中针对失败的测试实现了重试机制。

我正在寻求有关优化 CI/CD 管道的最佳方法的建议，以提高速度、降低故障率并确保稳定性。任何有助于简化流程的建议、最佳实践或工具将受到高度赞赏。

Answer 1

我认为你可以介绍一下与功能分支相关的初步工作。这种改进的工作流程可以如下所示：

• dev 创建功能分支
• 每次提交都会通过构建和选择性测试启动功能分支作业（或者可能仅启动一次，作为合并之前的最后一个先决条件）
• 成功完成后，代码将被合并（如果没有，开发人员会修复它）
• 这将启动主管道（构建和您描述的所有测试（负载测试除外））
• 负载测试仅在夜间在单独的作业中运行

功能分支作业不会运行所有测试，而只会运行与开发人员所做的更改相关的测试。我个人使用方法来运行该功能所涉及的模块中以及使用该功能的所有模块中的所有单元测试，但它并不是一成不变的。此外，仅应运行与功能相关的 E2E 测试。这并不容易映射，但我只是使用文本文件说触摸 moduleA 应该触发 E2Etest1 和 E2Etest5 等等。没关系，这或多或少是正确的，因为这只是主管道启动之前的一般检查。 在主管道中，所有测试都会运行，因此如果远程功能依赖性出现任何问题，或者一般安全网在初步工作中不够密集，缺陷无论如何都不会到达生产环境。 正如我所说，我不会在每次提交时都运行负载测试，而是每天一次。

这带来了许多优势：

• 初步工作减少了主管道的故障数量并提高了其稳定性，同时不影响 QA
• 减少负载测试频率可加快主管道速度

可以进一步改进，例如：

• 同时运行单元测试和E2E测试
• 同时运行大多数单元测试（我使用同时测试所有主要模块的方法）
• 识别非常繁重的 E2E 测试并每天运行一次，就像负载测试一样