Hi all! We are looking at BDCT using Pactflow. I'd love a sanity check on some of my thinking on the practical workflow. Say a developer on a Provider team makes a deliberate breaking change to an endpoint and updates the OAS accordingly. The API tests would have to be updated at the same time to ensure the contract which will be generated from the OAS matches the change being made to the endpoint. To allow a test specialist to update the API tests, would you then have the developer and test specialist make their changes on the same branch (whether it be async or in a pair programming session)? How are others doing this? Also, say the Consumer is ready with an update to match the change on the Provider side. The Provider isn't able to merge their change yet, because they're breaking a Consumer. Because of this, the Consumer also isn't able to merge their change, because the Provider doesn't meet their new expectations yet. Is this resolved by the Provider and Consumer using identically named branches in their respective repos so that the contracts can be tagged and verified against their working branches? Or is this where the WIP Pacts feature would tell the Consumer that they get a fail for the main branch but they may get a pass from the WIP pacts which includes the new Provider one and which will unblock that Provider? confused dog 2741

For the merging a provider's breaking change question I've just used this part of the original pact FAQ before. It's not BDCT specific but I feel it doesn't really matter and still applies that any changes should be backwards compatible with consumers. I'm still learning BDCT myself so there may be another way!

I don't know much about how BDCT are supposed to work, but I agree with Ben. In OAS documentation, there's often definitions of breaking changes like "removing an endpoint" or "renaming a field". This is overly wide - it's not a breaking change to remove an endpoint that no one is using. In Pact, the definition of breaking change is any change to an API which actually causes a failure in a consumer or provider. Pact isn't supposed to enable you to make this kind of breaking changes, it's supposed to help you not make breaking changes, so that you can safely deploy with no downtime. Even without pact, how would you deploy a completely breaking API change safely? Unless you can atomically deploy the consumer and the provider, you'd still need a consumer that can talk to the old and new provider.

What everyone said. This faq is our recommended practice for breaking changes, but is pretty much the above.