对齐前端/后端CI和CD

Question

我们有两个git repos：

• 前端（主要是TypeScript）
• 后端（提供HTTP API）

示例：

1. 开发人员将代码推送到前端存储库。前端现在有版本0.5
2. CI针对后端版本1.1测试了更改。
3. 一切都很好，所有测试都通过了。
4. 前端代码已部署到生产系统
5. 存在重大故障，因为生产后端仍在1.0版上

如何避免这种情况？

更新

在“世界”包中，您可以定义依赖项。例如使用rpm / dpkg / pip / npm。在上述前端/后端方案中，您还需要定义一个依赖项：

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

Answer 1

如果要获得完整的CI / CD，则contract testing and/or functional testing是绝对必须的。

系统是否遵循更严格的design by contract，很明显，这是零件之间的合同，是子系统之间如何通信的共同协议，例如，您的后端的API响应是什么？前面需要。

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

如何执行此操作？

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

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

2. 您需要使用任何工具来进行API测试，功能测试，合同测试。非常REST-Assured和Runscope（现在属于Blazemeter）这让我非常安心的非常普通的变量，因此您可以利用API监视，功能测试和许多其他功能）。此外，我没有使用它们，但是您可以研究pact.io和pactflow.io，有些人似乎在consumer-driven contract testing with Postman和总体上continuous API testing with Postman的情况下使用newman

的帮助

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

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