我正在编写一个由多个微服务组成的API。我在私有 Gitlab 存储库中有代码。我有一个自定义的 CI/CD 管道，配置为在每次提交到 master 时自动运行几个不同的步骤(例如，构建、测试、部署到开发环境(。部署到生产是手动的。
我围绕这段代码编写了一些单元测试，它们自然只测试代码的一小部分单元。当然，这些是在每次提交时运行的，因为如果它们失败，那就意味着代码中的某些内容已经中断。
我也有我们在部署后运行的回归测试。其中一个实际上是一个 bash 脚本，它使用 curl 使用某些参数命中我的生产端点，并检查以确保我得到 200 个响应。我已经参数化了这个脚本，所以我可以轻松地将其指向我的开发环境(而不是 prod(。
我使用此回归测试(以及其他类似的测试(来检查已部署的服务是否正常运行。我在部署后立即运行它作为最终，仔细检查以确认一切正常。但我想自动化它。
我的问题是这在 CI/CD 工作流中的位置？对提交运行这种回归测试是没有意义的，因为该提交不一定与部署相结合。而且因为服务可能关闭的原因有很多，这些原因与最近提交的任何代码更改无关。换句话说，管道不应该因为外部环境而失败。
是否有运行和自动化回归测试的最佳实践？
好问题。这里有几个有趣的观点。
- 何时在CI/CD环境中运行回归测试(目前存在(。
对此的明显答案是作为部署后步骤运行。使用当前用于将部署步骤限制为主分支的相同方法，您可以将此部署后步骤限制为主分支。
如果添加有关环境的更多详细信息。例如，您正在使用的CI/CD系统和当前的配置，我很乐意提供有关如何实现这一目标的更具体的详细信息。
- 对
- 提交运行这种回归测试是没有意义的
我见过几次的有趣方法。正在使用云服务(AWS/GCloud等(在每次CI运行时启动环境。这意味着可以为每次提交运行完整的管道。虽然它需要更多的资源，但这意味着您可以在合并到主数据库之前发现问题。当然，投资回报率是否在您的环境中累积取决于您。