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