https://pact.io logo
Join Slack
Powered by
Hi. I managed to convince my team to give <Pact.io...
# general
j
Hi. I managed to convince my team to give Pact.io a shot. We have a GraphQL provider, and multiple consumers, but focusing on a single one right now. We are working using git flow - feature branches, develop branch that we merge FB to, and then master branch for production-ready code. We have introduced can-i-deploy on develop/master branches, that checks against current environment (
staging
for develop branch, and 
production
for master branch). We have noticed a potential obstacle: • have a query 
User{fullname}
, • lets assume we want to change that query to return firstName, lastName our initial thought was: • lets change the provider to return 
{firstName, lastName, fullName}
• then we are able to make changes in the consumer, and deploy to 
staging
• then we are able to remove the redundant & unused 
fullName
from the provider, and deploy to 
staging
that would work okay for develop branch, but then if code gets merged to 
master
, we wouldn't be able to deploy provider (as the currently deployed 
production
consumer still requires 
fullName
to be passed) and in such case, we are unsure how to proceed.
Consulting a friend led to another idea: feature toggles. We would be able to pass a consumer version to the backend and because of that, backend could select which implementation should be used. However, that seems like a commitment on backend team's side to always ensure every query is supported when breaking changes occur. And I don't think we like that idea.
So how do we deal with existing interaction changes?
(just to be clear: the first post's idea would work if we DIDN'T remove redundant attribute in the 
develop
branch. Then, we would still be able to push to master and deploy code to production. However, i'm worried about cases where developers will forget that this 
fullName
is still required on the currently-deployed production consumer, and thus it will lead to git chaos because we would have to revert some just merged commits in order to get back to a point where the redundant attribute is not yet removed, deploy, and then remove.)
t
Are you failing the build on a failed verification, or on a failed can-i-deploy?
Pact prevents you deploying a breaking combination of consumer and provider
so, you need to have a path to deployment that is never breaking - for a "breaking change" this means deploying either a consumer that can speak to both providers, or a provider that can speak to both consumers.
it's worth noting that, whatever your branching strategy, pact just exposes this problem. You would have the same problem without pact, it just wouldn't block deployment.
j
Yes, correct. This is not a pact problem, but more of a "let's make sure what is live, never breaks" 🙂
I'm just trying to find an optimal solution to this. We would be failing on a failed verification on the provider side, and also can-i-deploy on consumer side.
t
You might find it helpful to not fail if verification fails, but to fail only during can-i-deploy
j
Yeah, we have enabled pending contracts in feature branches.
🙌 1
But overall I guess the real question is: how do you develop without ever breaking the path to deployment? How do we ensure developers do not forget of the production installments, and the fact that they can't just change interactions?
I guess just backend has to be ready to serve both ways? Or we should create new queries (that reflect new interactions) on the consumers side?
b
I think the only option is to keep the compatibility window open on both sides, until it's safe to remove the old functionality. https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider Hopefully the lead time to release isn't too long, so it's not a hassle to support both versions.
It's also customary to check can-i-deploy for both the feature branch and the main branch in CI, pre-merge
if main is ahead of prod, then check against prod, too
Open in Slack
PreviousNext
Powered by