Pact 契约：如何防止消费者产生不正确的合同

我们有两个微服务：提供者和消费者，两者都是独立构建的。消费者微服务（Consumer micro service）在使用提供商服务时出错（无论出于何种原因），因此，向pact代理发布了不正确的pact。 消费者服务构建成功（并且可以一直发布！），但下一个提供者服务构建将由于错误的原因失败。因此，我们最终得到了一个坏的提供者服务构建和一个坏的消费者发布

预防这种情况的最佳做法是什么

我希望Pact Broker能够在合同发布时自动触发提供者测试，并在失败时通知消费者，但事实似乎并非如此

---

谢谢

你说得对，这是当前Pact工作流程中缺少的东西之一，我一直在努力实现这一点，只要其他一些东西保持一致

话虽如此，但这并不能解决您当前的问题，因此我将建议您在流程中采取一种潜在的解决方法。您可以在使用者上运行测试，然后等待提供者测试返回绿色，然后再一起释放使用者/提供者，而不是为使用者运行测试，让他们通过测试，然后立即释放测试。另一种方法是对提供者/使用者交互（api版本控制）进行版本化，以便您可以事先释放使用者，但在发布提供者的正确版本之前不会“打开”

这些解决方案都不是很好，我完全同意。这是我非常感兴趣的事情，我将很快致力于修复pact broker的开发者体验，并以更好的方式发布消费者/提供者

---

欢迎提出任何意见。干杯。

我认为问题可能是由于合同是在消费者方面产生的。这意味着消费者可以根据自己的意愿修改这些合同。但最终，由于消费者产生了不正确的合同，生产者的构建将受到影响。 有没有办法让生产商定义合同？因为我认为生产商有责任维护自己的合同。例如，对于Spring云合同，建议在生产者来源中定义联系人（例如，在具有生产者源代码的同一git repo中），或在生产者和消费者可以一起管理的单独scm repo中定义联系人

这就是消费者驱动的契约的本质——消费者在API中拥有重要的发言权

作为一般规则，如果契约没有改变，就不需要运行提供者构建，尽管目前在代理中没有简单的方法知道这一点（请参见功能请求）

至于解决方案，您可以使用以下一种或多种策略

有效使用代码分支

当然，在消费者可以安全释放之前，供应商必须验证合同中的新假设，这一点非常重要。在合并到主服务器之前，对提供程序进行分支测试

但最重要的是，您必须与提供商团队密切合作

使用源代码管理检测修改的合同：

如果您还将主pact文件签入源代码管理，您的CI构建可能会有条件地起作用-如果契约已更改，您必须等待绿色提供程序构建，否则您可以安全部署

存储在单独的存储库中

如果您确实希望提供者维护控制权，可以将合同存储在提供者管理的中间存储库或文件位置中。我建议这是最后的手段，因为它否定了合作协议旨在促进的大部分内容

使用Pact Broker Webhook:

我希望Pact Broker能够在合同发布时自动触发提供者测试，并在失败时通知消费者，但事实似乎并非如此

是的，这可以在Pact Broker上使用。您可以在向服务器提交新合同后立即在提供程序上触发构建

您可以设想使用选项1和2执行此步骤

---

有关此用例的更多信息，请参见常见问题解答。

非常感谢！很高兴知道你已经计划好了@尤里索科洛夫斯基当然想知道更多关于你目前的工作流程。如果您有5分钟的空闲时间，请通过我的个人资料向我发送消息/电子邮件。干杯，你说得对。在我们与基金会成员的最后一次协议中，我们讨论了如何将这一点从“消费者驱动的合同”改为“合作驱动的合同”，以便消费者和供应商的输入都可以双向进行。关于这方面的更多信息：）您可以始终将合同存储在提供商团队管理的单独回购/位置。我会将此添加到我的回答中感谢@MatthewFellows的评论。事实上我已经这么做了。而且好多了。因此，现在我在一个单独的git存储库中有几个Junit测试，其中包含状态注释，描述如何将提供程序切换到特定状态（FYI提供程序使用docker compose规则作为docker容器运行）。我运行这些测试来验证生产商是否符合合同。但契约本身仍然使用Pact注释在消费者的集成测试中定义。我希望能够在我的contracts git存储库中将这些契约与集成测试分开。正如J_A_X所指出的，这是目前还没有的东西，但希望感谢您的详细建议和一些新的想法。我喜欢将提供者测试作为消费者管道的一部分来运行的想法。为了实现这一点，我们可能需要将提供者测试包括到提供者Docker映像中，并有一种触发测试的方法。不用担心！只是要小心，您希望避免总是必须运行提供程序构建af