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