澄清测试在管道中的位置

Question

我正在阅读一些东西，这让我怀疑我是否正确地在我的管道中实现测试。

我目前的设置如下:

• 推送到远程的微服务的本地特性分支
• PR请求将特性请求合并到testing分支用于微服务
• 已接受并合并
• 触发CI/CD管道:
  • 首先，创建一个Linux虚拟机
  • 微服务部署到虚拟机
  • 为微服务
  运行测试
  • 如果所有测试都通过了，它会构建Docker镜像并将其推送到容器注册表
  • 部署阶段然后提取映像并部署到Kubernetes集群

我的问题如下:

• 开发者应该在本地进行测试，但是测试应该在PR提交时自动发生吗?
• 我应该先构建Docker镜像，创建镜像的运行容器并测试它(这毕竟是要部署的)吗?

换句话说，是流:

1. 构建app ->测试→如果通过，则构建image ->部署
2. 构建图像->测试→如果通过，部署
3. 构建app ->运行某些测试->如果通过，则构建image ->运行更多的测试->部署

谢谢你的解释。

Answer 1

这里有几件事我要重新安排一下。

正如@DanielMann在评论中指出的，你的服务应该有大量的单元测试。它们不需要在容器中运行，也不依赖于任何外部资源;您可以使用服务客户机的模拟实现，或者使用SQLite等替代实现作为进程内数据库。一旦您的CI系统看到提交，在构建映像之前，它应该运行这些单元测试。

然后您应该针对拉取请求运行尽可能多的测试序列。(如果在合并到主分支之后集成测试失败，则构建失败，如果需要紧急修复，则可能会出现问题。)特别是您可以从PR分支构建Docker映像。根据你的系统设置，你可以直接进行测试;可以使用备用的纯docker环境，或者在专用的Kubernetes命名空间中，或者使用本地Kubernetes环境，如minikube或kind。

绝对要测试你在生产环境中运行的Docker镜像。

总之，我会重新安排你的工作流程:

1. 推送到远程的微服务的本地特性分支
2. PR请求将特性请求合并到testing分支进行微服务
   1. 触发CI管道:
   2. 运行单元测试(不带Docker)
   3. 构建Docker镜像(并可选择推送到注册表)
   4. 部署到一些测试设置并运行集成测试(使用Docker)
3. 已接受并合并
   1. 触发CI/CD管道:
   2. 运行单元测试(不带Docker)
   3. 构建Docker镜像并推送
   4. 部署到生产环境