0

我读过类似这样的文章，这些文章建议在提供者端验证存在于消费者功能分支中的合同，实际上允许合同在合并到主控之前进行“预验证”。但是，我已经阅读了 Pact 团队的其他文档，说明相反。在The Steps to Reaching Pact Nirvana中，它指出“为了在您的提供商的 CI 中保持绿色构建，而不是验证最新的整体协议，它应该验证 CI 中标记为“master”的最新版本的协议。” 在这里，我假设“最新的整体协议”是指可能存在于发布到 Pact Broker 的消费者功能分支中的协议。

我很困惑。为了不“让提供者团队不高兴”，如The Steps to Reaching Pact Nirvana中所述，如果提供者永远不会验证该协议并且只验证“主”和“生产”协议？另一种问这个问题的方法是什么时候会/应该从功能分支发布/验证协议，而不是消费者和提供者的主分支反对“主”和“生产”协议？

4

1 回答 1

1

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

但万一不是，预验证功能分支绝对是 Broker 的核心功能，也是我们想做的事情。一旦更改在 master 中，在 99% 的情况下它应该是一帆风顺的（即兼容的）。标准做法是 a) 有一个 webhook 可以触发提供程序构建的协议验证步骤以验证新功能，或者 b) 让提供程序中的相应功能分支在推送更改时验证 CI 中的协议。

还有一个新功能即将推出，称为“待定协议”，它也将极大地改善这种情况，有效地允许任何新合同不会破坏提供者的构建，但如果支持更改，仍会向消费者提供反馈。

于 2020-01-21T12:22:49.797 回答