Hi everybody, I have a couple of questions about the can-I-deploy tool: 1. As an example, I have multiple released + supported versions of a consumer and a provider in production. I now want to release a new version of the provider, how does the can-I-deploy tool figure out if I can release? Does it just check though the provider verification results and only allow release if the new provider is completely backwards compatible with ALL consumer releases? 2. Second example, I have multiple deployed consumer versions each with an application instance, and multiple versions of provider each with an application instance. Now I want to deploy a new provider version onto one of the instances, does this new version need to be compatible with all deployed versions of the consumer?

1) Yes, it will only let you deploy if you are compatible with all releases in that environment. 2) I don’t think I understand this question. What do you mean by “application instance”?

Thank you @Timothy Jones! By application instance I meant the optional attribute we supply to

record-deployment

command. I saw it from this section of the doc. https://docs.pact.io/pact_broker/recording_deployments_and_releases#recording-deployments

Oh, I see. I didn’t know about that option. I don’t know, I’m afraid - you’ll have to wait for someone else who can answer.

Hi everyone, a follow up question about

can-I-deploy

tool, say if we have consumer v1 and provider v1 already deployed in production. Now we have consumer v2 and provider v2, which works with each other but both include breaking changes for provider v1 and consumer v1 respectively. What is the recommended way to deploy v2 to production? (I think if we tried to use can-I-deploy it will fail because if we run it for consumer v2 it will say it’s not compatible for provider v1 and vice versa). Thank you in advance!

you could use an expand and contract pattern, • contract testing highlights the incompat ◦ provider and consumer deployed are compat, provider makes breaking changes, both dev versions of provider and consumer cannot be deployed • you update one side of the code to support it ◦ consumer to deal with old and new change ◦ provider to deal with old and new change • contract testing says a-ok • you deploy all the things ◦ backwards compat provider or consumer gets deployed • contract testing then allows you to remove the things ◦ consumer can stop calling old provider change ◦ provider can stop producing old change ◦ everyone is compatible with the new things Your mileage and exact steps depend on your use case. There are times where it's unavoidable, you can skip the can-i-deploy checks or allow the job to fail but proceed with deployment, this might co-incide with planned downtime

Absolutely. Contract testing just highlights this problem, but it exists if you don’t have one side speak both versions, regardless of whether or not you catch it.

Thanks @Yousaf Nabi (pactflow.io)! This makes a lot of sense

I would definitely advise you against doing this.

Thanks Timothy, could you please help me understand why deploy instantly makes a difference?

Because if you deploy everything together, there will be periods where some services are not on the new version yet, but some are.

Ok that makes sense, I think I also didn't explain our situation well enough, sorry. In our case the product we are releasing is binary code. From our perspective something could be considered as released once the binary is made available to the end users. It also means we are technically not deploying/running the code ourself. As what we are working on isn’t a server we are not worried about outages, but we do want to keep track of compatibility of different major versions of our applications which are designed to work together. I hope that makes sense.

ah, sure. In that case I would consider a major version an “environment”, yes.

Thats great, Thank you!