Pact CDC测试最佳实践

Question

我读过类似这样的文章，其中建议在提供者端验证存在于使用者的特性分支中的契约，实际上允许在合并到master之前对契约进行“预验证”。然而，我读过来自Pact团队的其他文档，说明了相反的情况。在达到契约涅槃的步骤中，它声明“要在您的提供商的配置项中保持绿色构建，而不是验证最新的整体契约，它应该验证配置项中标记有”master“的最新版本的契约。”在这里，我假设“最新的整体协议”是指发布给协议代理的消费者特性分支中可能存在的协议。

我很困惑。为了不让提供商团队不高兴，就像达到协议涅槃的步骤中所说的那样，如果提供商永远不会验证用户的特性分支的协议，而只是验证“主”和“生产”协议，那么发布该协议的目的又是什么呢？另一种问这个问题的方式是什么时候/应该从特性分支发布/验证契约，而不是仅仅从消费者和提供者的主分支针对“主”和“生产”契约发布/验证契约？

Answer 1

请注意，这是关于“有效契约设置”的最新指南:https://docs.Pact.io/best_practices/pact_nirvana。希望这更清楚。

但如果不是，预验证特性分支肯定是代理的一个核心特性，也是我们想要做的事情。一旦改变在master中，在99%的情况下它应该是一帆风顺的（即兼容）。标准做法是a）有一个webhook，它可以触发提供程序构建的协议验证步骤，以验证新特性，或者b）在提供程序中有相应的特性分支，在推送更改时验证配置项中的协议。

还有一个新特性即将问世，叫做“未决契约”，它也将极大地改善这种情况，有效地允许任何新契约都不会破坏提供者的构建，但如果支持更改，它仍然会向消费者提供反馈。