Hi there :wave:! I deployed both consumer and prov...
# pactflow
t
Hi there 👋! I deployed both consumer and provider to the environment "dev" in Pactflow with a successful validation. Now, I'm trying to simulate a breaking change in the consumer API, I renamed an existing field. Using can-i-deploy doesn't allow me to deploy neither the consumer nor the provider with the new versions. Can you please guide me to the right direction here? Which side should I deploy first and how I do that when having these scenarios? Thanks in advance.
m
Have you taken a look at the CI/CD workshop? (see link below - howtolearn 👇 )
👍 1
s
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
m
I suspect you’ll need to work on branches/tagging to prevent getting into this situation.
b
Also, in case it's not clear from here, if you want to make a breaking change like that, you can make it safe by doing it in smaller steps: https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider
🙏 1
m
ah, good share - thanks!
👍 1
t
Thanks, guys. I understand the concept of the "expand and contract pattern," and it's really helpful. However, I'm a bit confused about the statement regarding working on "branches and tagging to prevent getting into this situation". In my understanding, branches and tags function similarly. I currently use branches to publish the contracts. I can publish a new contract with a breaking change to a feature branch, update the provider to support this breaking change in a branch with the same name, and validate the tests. However, deploying a breaking change can still be challenging as it will block deployment to an environment. The only solution I see is to skip the
can-i-deploy
step in the consumer pipeline and coordinate a subsequent deployment of the provider with a code that supports the new contract. Apart from that, I will recommend to my team that we always follow the "expand and contract pattern" as it seems to be a safer approach.
👍 1
m
Yes, a breaking change is breaking regardless of the use of branches etc. That was a poor suggestion on my part not fully seeing the real problem