hi @Matt (pactflow.io / pact-js / pact-go) , I had connected with Mike and I wanted to connect you with some of our engineers at Lasso MD so that we can validate some of our practices and see if there are more efficient ways to do manage consumer/producer tests, ci/cd pipeline and releases

hi @Matt (pactflow.io / pact-js / pact-go) we have this case where Pactflow reports that the pact test was successful but in our github action it fails and does not pass the test. How can we avoid these cases?

Another question. How can we narrow our verification to deployed versions to an specific environment? Let's say we do record deployments to dev, staging and prod, but we only want to verify against

dev

Hey guys, just checking in - did the above conversation help move things forward for you?

It sounds like you’re still working out the best gating strategy: 1. The PR for

service-database

builds successfully. 2. The PR for

service-roi-core

fails in the “*can-I-deploy*” step because the new endpoint does not exist in any environment, leading to a verification failure. 3. The PR for

service-database

is merged and deployed to the development environment only. 4. The PR for

service-roi-core

is rechecked and fails again in the “*can-I-deploy*” step because service-database was not deployed to non-prod and production. 5. The PR for

service-roi-core

cannot be merged until we manually release service-database to non-prod and production. Options you listed to address this a) Create mirror environments for non-prod and production that will have continuous deployments happening to them. b) Skip the “*can-I-deploy*” step for environments other than dev in the PR validation. This will allow us to merge to main in service-roi-core in the example above, but then the “*can-I-deploy*” step that occurs during the actual deployment to non-prod (depicted in the Pact link above) will most likely fail because the deployment to non-prod in service-database hasn’t happened yet. We would need to perform two manual releases to have everything in non-prod and then two releases to have everything in production. c) Only run “*can-I-deploy*” for dev in the PR validation and deploy to dev. This would defeat part of the purpose of why we implemented Pact in the first place.

> b) Skip the “*can-I-deploy*” step for environments other than dev in the PR validation. This will allow us to merge to main in service-roi-core in the example above, but then the “*can-I-deploy*” step that occurs during the actual deployment to non-prod (depicted in the Pact link above) will most likely fail because the deployment to non-prod in service-database hasn’t happened yet. We would need to perform two manual releases to have everything in non-prod and then two releases to have everything in production. This seems the most logical decision to me. The can-i-deploy tooling is just going to model the process they have. If you aren’t following continuous deployment and are manually deploying and validating each stage, then the can-i-deploy tool should mirror the deployment model. That is, each time you plan on deploying to another environment, you should invoke can-i-deploy and after the deployment, call record-deployment. > but then the “*can-I-deploy*” step that occurs during the actual deployment to non-prod (depicted in the Pact link above) will most likely fail because the deployment to non-prod in service-database hasn’t happened yet. We would need to perform two manual releases to have everything in non-prod and then two releases to have everything in production. I don’t understand this point. If you aren’t doing continuous delivery and deploying to all environments straight away, then it’s telling you what you would expect – the application is not safe to release.

Hi @Kwan Lee and team, just sending you a friendly reminder that we are waiting for your reply. Thank you!

@Gabriel Ferrarini pinging for visibility...

@Michael DaSilva tks for pinging me. I'll read this today and get back to you. I hadn't looked at the channel in the past few days