continuous-integration - 如何在不破坏 Pact 合同的情况下向提供者和消费者代码添加新功能？

Question

管道

我正试图让我的管道尽可能接近协议必杀技，减去部署到测试，因为我仍在使用这项技术。

请注意，我使用的是代理的开源版本，而不是 pactflow。

提供者管道

• 建造
• 测试
• 根据最新的生产标记消费者协议进行验证（最新的提供者版本化为 git sha，标记为 git 分支）
• 如果最新标记的生产消费者模拟已通过针对最新提供程序版本的验证，请使用 can-i-deploy 检查协议矩阵。
• 部署
• 在协议代理中将最近部署的提供程序版本标记为生产

消费者管道

• 建造
• 测试并发布到代理（最新的消费者版本化为 git sha，标记为 git 分支）
• webhook 在提供者管道中针对生产标记提供者执行新发布的消费者版本的验证
• 使用 can-i-deploy 检查代理中的协议矩阵以确定最新的消费者模拟是否已通过针对最新标记的生产提供者的验证
• 部署
• 在契约代理中将最近部署的消费者版本标记为生产

问题

当我尝试构建新功能时，这会分崩离析。

假设我创建了一个更改，通过更改提供者对非常不同的东西的响应来打破消费者和提供者之间的合同（想象一下它对消费者来说是一个新功能）。这显然在管道内的验证步骤中失败了，因为我们正在根据生产标记的消费者对其进行检查。

然后我们改变消费者模拟（和代码）来消费这个新的响应。然后我们推送到启动 CI 的存储库，并在验证步骤失败，因为我们正在针对生产标记的提供程序（不是具有功能分支名称的最新标记）进行测试。

显然，我们总是希望针对带有生产标签的对应物（与 can-i-deploy 相同）进行验证，以防我在消费者或提供者代码库中意外创建了重大更改。

所以我们有一个catch-22的情况；我们如何在不破坏推荐管道的情况下添加需要修改消费者和提供者代码的新功能？

标签： continuous-integrationproducer-consumerpact

Answer 1

https://docs.pact.io/faq#how-can-i-make-a-break-change-to-a-provider

如果您需要对提供程序进行重大更改，您可以使用扩展和收缩模式在多步骤过程中进行。

将新字段/端点添加到提供程序并进行部署。更新消费者以使用新的字段/端点，然后部署。从提供程序中删除旧字段/端点并进行部署。在流程的每一步，所有合同测试都保持绿色。消费者驱动的合约很好地支持这种模式，因为提供者很容易通过在本地开发环境中删除旧字段并运行协议验证测试来确定所有消费者是否/何时放弃使用旧字段。