I have a query - if we have a new Pact published by consumer, where can-i-deploy for consumer fails for QA and Prod environments since Provider is not yet upgraded on QA and Prod. Then if we modify Provider to support new Pact published by consumer and found verification fails for QA and Prod environments and hence the can-i-deploy for provider also fails for QA and Prod environments, then how the applications will get upgraded since both consumer & provider deploy pipelines will fail at their end?

what is the type of change? If the provider isn't backwards compatible with the deployed consumers on the feature branch, you won't get a valid output from can-i-deploy for both the latest from the consumers main branch and the deployed versions. You can either 1. Make the provider forwards and backwards compatible with the deployed consumer and the consumers new requested change, deploy provider and then deprecate the old behaviour from the consumer and provider respectively 2. Know that from your C-I-D that your provider to be deployed is compatible with your consumer to be deployed, but not compatible with the deployed consumers. In this case, I suppose you need to be organise a release where both services go out within for example an outage window, where you expect there to be a short downtime, whilst you deploy your latest consumer and provider. Option 1 leads you to near on to zero downtime, but its slightly more complex. In either situation Pact is providing you the contextual information to decide which route might be best for you

So in #2 approach, do we have to disable can-i-deploy in the pipleline for our scenario?

https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy you can use the dry run flag, by env var

[--dry-run], [--no-dry-run]
              # When dry-run is enabled, always exit process with a success
                code. Can also be enabled by setting the environment variable
                PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true. This mode is useful when
                setting up your CI/CD pipeline for the first time, or in a
                'break glass' situation where you need to knowingly deploy what
                Pact considers a breaking change. For the second scenario, it
                is recommended to use the environment variable and just set it
                for the build required to deploy that particular version, so                 you don't accidentally leave the dry run mode enabled.