对齐前端/后端CI和CD

Question

我们有两个git回复：

• 前端(主要是TypeScript)
• 后端(提供HTTP )

示例：

1. 开发人员将代码推送到前端回购。前端现在有0.5版
2. CI对后端1.1版本的更改进行测试。
3. 一切都很好，所有的测试都通过了。
4. 前端代码被部署到生产系统中。
5. 有一个重大的失败，因为生产后端仍然在1.0版上

如何避免这种情况？

更新

在包"world“中，您可以定义依赖项。例如，rpm/dpkg/pip/npm。在上面的前端/后端场景中，您还需要定义一个依赖关系：

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

Answer 1

如果您想要实现完整的CI/CD，那么合同测试和/或功能测试是绝对必须的。

无论系统是否遵循更严格的按合同设计，清楚的是这是一个部件之间的契约，一个关于子系统如何通信的相互协议，例如，来自前端所需的后端的API响应是什么。

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

怎么做？

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

- Some people enforce [consumer-driven contracts](https://pactflow.io/blog/what-is-contract-testing/). This simply states a philosophical position that advocates for putting the consumers of APIs at the heart of the design process. 
- Some others will prefer to let the backend drive. 
- In some cases, this is unpredictable, and consumers or providers could need to drive the change in different moments, or in certain microservices mesh, consumers are producers and producers are consumers. 

​

1. 您需要为任何API测试、功能测试、合同测试提供任何工具。非常正常的是放心和运行范围 (现在属于巴兹表，所以您可以利用API监视、功能测试和许多其他特性)，它们给了我很大的安全感。而且，我没有使用它们，但是您可以查看pact.io和pactflow.io，有些人在纽曼的帮助下做与邮递员进行消费者驱动的合同测试和一般的基于邮递员的连续API测试似乎有很好的效果。
2. ，最后，在CICD中实现测试。根据您的工作流程和可用的工具，您需要

- decide where to keep the contracts, this can as schemas in one of the repos (i.e the frontend, the backend) or in a separate repo just for API schemas or test description, or in the tool itself.  
- decide how to run the tests. For this, since you are already running tests (I imagine at least unit/integration) in your CI/CD pipelines, you will just need to add the needed steps for also validating all contracts whenever any subsystem is deployed. So it will not go to production if any of the other subsystems are not in the required version, producing the expected schemas. 
- update your schemas FIRST, whenever one of the subsystems is using new requirements. I.e in your case, frontend needs backend version 1.1, so when you are writing the changes in the frontend, you already know what are the changes, so you can update the schemas used in the testing. When deploying to any environment, the deployment will succeed only in the environments in which the contract test passes. I.e it may work in sandbox/dev/QA environments if backend 1.1 is already there, but then if in production is not there, the CICD will stop since the contract test will not pass. 

​