了解Pact Broker工作流程

Question

完全了解，有很多类型的工作流程可以用于不同的Pact集成方式，我试图想象一下常见的工作流程是什么样的。我开发了这个Swimlane for Pact Broker Workflow。

1. 我们如何在较旧的Provider构建版上运行提供程序验证？
2. 这如何随标签而变化？
3. 何时将webhook创建回提供商？
4. 如果不同的提供商有不同的基本网址（即构建系统）怎么办？
5. 如果提供商失败，新的提供商如何建立有关消费者的警报？
6. 我是否正确考虑过此流程？

我试图从Webhooks，Using pact where the consumer team is different from the provider team和Publishing verification results to a Pact Broker 收集我的理解。假设我正在以正确的方式思考问题并且没有完全错过一些文档，我很乐意为社区写一份建议工作流文档。

Answer 1

您的泳道图是一个很好的工作流程图，但需要注意的是，一旦完成所有设置，很少从代理手动启动提供程序构建。

提供商不会在此过程中通知消费者有关验证失败（或成功）的信息。如果确实如此，那么你最终可能会得到循环构建。

我这样想：

• 消费者测试创建合同（Pact文件）。
• 此步骤还验证消费者是否可以与履行该合同的提供商合作（使用模拟提供商）。
• 然后，消费者将此Pact文件提供给代理（如果配置为这样做）
• 现在有一个新的协议，代理（如果已配置）可以触发提供者构建
• 提供商的CI基础架构构建提供商，并运行协议验证
• 提供商的CI基础架构（如果已配置）告诉代理有关验证结果的信息。

代理和提供者的构建系统是唯一知道验证结果的位 - 目前它不会传递给消费者。

通过测试的消费者意味着消费者可以说“我已经写了这份通信合同，并确认我可以坚持自己的一面”。未能在提供商端验证合同不会更改此声明。

但是，如果验证成功，您可能希望触发使用者部署。正如Beth Skurrie（Pact的主要贡献者之一）在下面的评论中指出：

  

将验证状态传达给消费者实际上是一件非常重要的事情，因为它告诉消费者他们是否可以安全地部署。这是目前协议工作流程中缺失的一部分，我正在努力尽快纠正这个问题。

目前，由于验证状态是您可能想要了解的信息 - 特别是如果您无法看到提供商的CI基础架构 - 您可能希望查看更轻松的协议build badges检查经纪人。