使用单独的前端和后端repos的合同测试

Question

我们正在为我们的CI-CD使用代码管道。

前端和后端是独立的存储库。

我们对前端和后端的部署进行了端到端的测试。

代码从特性分支-> dev ->暂存-> prod合并，并启动各自的管道。

我期待着整合合同测试。在部署API网关时，我们已经生成/存储了swagger文档。

我认为，为了模拟消费者驱动的合同测试，在部署前端或后端的end 2端测试成功执行之后，我将从API网关下载swagger JSON文档，并将其存储在s3桶中，以便我可以使用它作为参考来检测开发/准备阶段的中断更改。

1. 我应该比较dev和staging以prod来检测破坏的更改吗？我不喜欢在部署到dev或暂存时从prod帐户中的s3桶引用JSON。
2. 我如何改进这个过程？
3. 我有什么选择？

我知道似乎每个人都在使用pact来进行合同测试，但我只是认为，当我们已经拥有了一个很好的API文档时，它就太过分了。

Answer 1

根据我的理解，您正在尝试利用Swagger / OpenAPI规范来检测破坏的更改。契约驱动开发应该可以帮助您实现这一目标。

以下是一些改进流程的建议

• 生成Swagger / OpenAPI规范
  • 生成的API规范可能并不总是与您的实现相一致。示例:如果您正在利用Swagger注释来生成API规范，那么我们可能会遗漏一些注释，如果您捕获流量以再次生成API规范，则取决于各种流量等等。简而言之，生成的规范可能不是完全可靠的。我建议利用生成的规范作为起点，然后彻底审查它。
  • 在API上以合同即试验的形式运行API规范，在与消费者共享之前检查它是否确实符合规范

• 与涉众共享OpenAPI规范
  • S3桶可能不适合与消费者共享API规范。
  • 内部使用者- API规范是代码，更好地存储在版本控制系统中，如Git。然而，将其保存在多个不同的repos中也会使协作变得困难。将您的规范存储在中央合同仓库中
  • 外部使用者-从您的中心契约存储库生成一个发布伪制品，并通过API网关或其他标准方法发布您的API规范。

• 关于您的问题，“我应该比较dev和slow以检测破坏的更改吗？”-- IMHO等待将您的提供者部署到API网关，这反过来会生成API规范，这是缓慢的反馈周期。
  • 最好从API规范开始，而不是依赖于提供者来生成它。
  • 下面是一个视频，介绍如何利用OpenAPI规范来检测本地和CI本身的破坏变化，而不是等待部署到更高的环境。