我们有两个微服务：Provider 和 Consumer，它们都是独立构建的。消费者微服务在消费提供者服务的方式上犯了一个错误（无论出于何种原因），结果，错误的契约被发布到契约代理。消费者服务构建成功（并且可以一直发布！），但是下一个提供者服务构建将由于错误的原因而失败。所以我们最终得到了损坏的 Provider 服务构建和损坏的 Consumer 版本。
防范此类情况的最佳做法是什么？
我希望 Pact Broker 可以在合约发布时自动触发 Provider 测试，并在合约失败时通知消费者，但似乎并非如此。
谢谢！
这就是消费者驱动合约的本质——消费者在 API 中拥有重要的发言权！
作为一般规则，如果合同没有更改，则无需运行 Provider 构建，尽管目前在 Broker 中没有简单的方法来了解这一点（请参阅功能请求https://github.com/bethesque/契约经纪人/问题/48）。
至于解决方案，您可以使用以下一种或多种策略。
有效使用代码分支
当然，在消费者可以安全地发布之前，提供者对合同的新假设进行验证是非常重要的。在合并到 master 之前，对 Provider 进行分支测试。
但最重要的是 - 您必须与 Provider 团队密切合作！
使用源代码控制来检测修改过的合同：
如果您还将主协议文件签入源代码控制，则您的 CI 构建可以有条件地执行 - 如果合同已更改，您必须等待绿色提供程序构建，否则您可以安全地部署！
存储在单独的存储库中
如果您真的希望提供者保持控制，您可以将合同存储在由提供者管理的中间存储库或文件位置。我建议这是最后的手段，因为它否定了许多旨在促进的合作协议。
使用 Pact Broker Webhook：
我希望 Pact Broker 可以在合约发布时自动触发 Provider 测试，并在合约失败时通知消费者，但似乎并非如此。
是的，这可以使用Pact Broker 上的网络挂钩来实现。将新合同提交到服务器后，您可以立即在 Provider 上触发构建。
您可以设想此步骤与选项 1 和 2 一起使用。
有关此用例的更多信息，请参阅我们的常见问题中的在消费者团队与提供者团队不同的情况下使用 Pact 。
你说得对，这是 Pact 工作流程目前缺乏的事情之一，而且一旦其他一些事情协调起来，这就是我一直在努力的事情。
话虽如此，与此同时，这并不能解决您当前的问题，因此我将在您的流程中提出一个潜在的解决方法。您可以在消费者身上运行测试，然后等待提供者测试返回绿色，然后一起释放消费者/提供者，而不是为消费者运行测试，他们通过，然后立即释放它。另一种方法是对您的提供者/消费者交互进行版本控制（api 版本控制），以便您可以事先释放消费者，但在发布正确版本的提供者之前不会“打开”。
这些解决方案都不是很好，我完全同意。这是我非常热衷的事情，并且将很快致力于修复开发人员与协议代理的体验，并以更好的方式发布消费者/提供者。
欢迎任何和所有的评论。干杯。
我认为这个问题可能是由于合同是在消费者方面产生的。这意味着消费者可以根据需要修改这些合同。但最终生产者的构建将因消费者生成的不正确合约而受到影响。有没有办法让生产者定义合同？我认为制片人有责任维护自己的合同。例如，在 Spring Cloud Contracts 的情况下，建议在生产者源中定义联系人（例如，在与生产者源代码相同的 git 存储库中）或在可由生产者和消费者一起管理的单独 scm 存储库中。