Testing 回归测试如何最适合CI/CD工作流？

我正在编写一个由几个微服务组成的API。我在一份私人Gitlab回购协议中有代码。我有一个自定义CI/CD管道，配置为在每次提交到主服务器时自动运行两个不同的步骤，例如构建、测试、部署到开发环境。部署到prod是手动的

我已经围绕这段代码编写了一些单元测试，它们自然只测试代码的小单元。当然，每次提交时都会运行这些命令，因为如果它们失败，则意味着代码中的某些内容已被破坏

我也有回归测试，我们在部署后运行。其中之一实际上是一个bash脚本，它使用curl以特定参数命中我的生产端点，并进行检查以确保得到200个响应。我已经参数化了这个脚本，所以我可以轻松地将它指向我的开发环境，而不是prod

我使用这个回归测试和其他类似的测试来检查我已经部署的服务是否正常运行。我在部署后立即运行它，作为最后的双重检查，以确认一切正常。但我想让它自动化

我的问题是，在CI/CD工作流程中，这在哪里合适？在提交上运行这种回归测试是没有意义的，因为提交不一定与部署耦合。而且因为有很多原因导致服务可能会停止，这些原因与最近提交的代码更改无关。换句话说，管道不应该因为外部环境而失效

---

是否有运行和自动化回归测试的最佳实践？

好问题。这里有几个有趣的地方

何时以CI/CD环境中现有的状态运行回归测试。 显而易见的答案是作为部署后步骤运行。使用当前用于将部署步骤仅限于主分支的相同方法，可以将此部署后步骤仅限于主分支

如果您添加有关环境的更多详细信息。例如，您正在使用的CI/CD系统和您当前的配置，我非常乐意提供有关如何实现这一点的更多具体细节

在提交上运行这种回归测试是没有意义的

---

这是一个有趣的方法，我已经见过好几次了。正在使用云服务AWS/GCloud等在每次CI运行时启动环境。这意味着每次提交都可以运行完整的管道。虽然需要更多资源，但这意味着您可以在合并到master之前找到问题。当然，ROI是否在您的环境中累积取决于您。

顺便说一句：卷曲端点以检查其是否响应200不是回归测试，而只是冒烟测试。回归测试是检查行为的测试：单元测试、集成测试、E2E测试。@emix很公平！那只是其中之一。我还有其他人实际评估数据和服务之间更复杂的交互