Continuous integration 对齐前端/后端CI和CD

我们有两个吉特回购：

• 前端（主要是打字脚本）
• 后端（提供HTTP API）

例如：

开发人员将代码推送到前端repo。前端现在有0.5版

CI根据后端版本1.1测试更改

一切都很好，所有的测试都通过了

前端代码被部署到生产系统

由于生产后端仍在版本1.0上，因此出现了一个重大故障

如何避免这种情况

更新 在包“world”中，您可以定义依赖项。例如，使用rpm/dpkg/pip/npm。在上述前端/后端场景中，您还需要定义依赖项：

前端v0.5需要后端v1.1

---

如果您想获得完整的CI/CD，则绝对必须

无论系统是否遵循更严格的规范，很清楚的是，规范是各部分之间的契约，是关于子系统如何通信的相互协议，例如，前端所需的来自后端的API响应是什么

例如，如果一个使用者需要一个特定API的新模式，或者一个生产者正在更新一个特定API的模式，正如您所描述的，那么事情就会崩溃。这就是为什么每次更新任何子系统时都必须验证合同的原因

如何做到这一点？

首先，您需要考虑您的开发工作流程

• 有些人强制执行。这只是陈述了一种哲学立场，主张将API的消费者置于设计过程的核心
• 有些人更愿意让后端驱动
• 在某些情况下，这是不可预测的，消费者或提供者可能需要在不同的时刻推动变革，或者在某些微服务中，消费者是生产者，生产者是消费者

您需要为任何API测试、功能测试、合同测试提供适当的工具。非常普通的，让我心平气和的是，和（现在属于，所以您可以利用API监控、功能测试和许多其他特性）。另外，我没有使用它们，但是你可以查看和，而且一些人似乎在和的帮助下取得了很好的效果

最后，在CICD中实施测试。根据您的工作流程和可用工具，您需要

• 决定将契约保存在何处，这可以作为一个repo（即前端、后端）中的模式，也可以作为单独的repo（仅用于API模式或测试描述）中的模式，或者作为工具本身中的模式
• 决定如何运行测试。为此，由于您已经在CI/CD管道中运行了测试（我认为至少是单元/集成），所以您只需要添加必要的步骤，以便在部署任何子系统时验证所有契约。因此，如果任何其他子系统不在所需版本中，它将不会投入生产，从而产生预期的模式
• 每当子系统中的一个子系统使用新需求时，首先更新您的模式。也就是说，在您的情况下，前端需要后端版本1.1，因此当您在前端编写更改时，您已经知道更改是什么，因此您可以更新测试中使用的模式。当部署到任何环境时，部署将仅在契约测试通过的环境中成功。也就是说，如果后端1.1已经存在，那么它可以在沙盒/dev/QA环境中工作，但是如果在生产环境中不存在，那么CICD将停止，因为合同测试将无法通过

---

这是一个典型的问题，没有技术解决方案，您的客户端和后端大多保持向后和向前兼容性。否则，您将无法部署未中断的客户端更改（也称为“常规”更改）