https://pact.io logo
Join SlackCommunities
Powered by
hi! i have some tricky question :slightly_smiling_...
# general
d
hi! i have some tricky question 🙂 lets imagine we have 2-week sprints • on monday FE as a consumer waits for BE as a provider to be deployed on dev env ( everything is fine ) • on tuesday BE deploys, FE is unblocked -> FE deploys ( still everything is fine ) • on wednesday BE as a consumer waits for FE as a provider to be deployed on dev env ( everything is fine ) • on thursday FE deploys, BE is unblocked -> BE deploys ( still everything is fine ) • on friday we have a release to be deployed on pre-prod environment but got a deadlock hide the pain harold ◦ BE as a consumer waits for FE ◦ FE as a consumer waits for BE how to deal with such deadlocks ?
t
This might be a dumb question, but why is your sprint cadence relevant?
Also, I don’t think I understand the scenario, sorry
Oh, is the scenario that you have two interdependent services: A -> B B -> A they’re deployed fine to a dev environment, but now you want to promote them both to pre-prod (for the first time), and you can’t because they’re interdependent?
👍 1
So, my question would be - is it possible to deploy one without the other?
For example, with HTTP endpoints, you can deploy a provider without a consumer
But with say SQS messages, you can deploy either end safely without the other (as long as the queue exists, which Pact doesn’t assert)
This exposes a hole in Pact’s reasoning. Pact assumes that providers can deploy without the consumer, which isn’t always true. It also assumes that consumers can’t deploy without the provider - which also isn’t always true
If your scenario wouldn’t be fixed by the ability to tell Pact which end can deploy with the other end missing, then I think you have a real deadlock - and Pact is just exposing it.
👌 1
For example, if you have two services which are both HTTP clients and servers, with A -> B, and B -> A ,it’s not possible to deploy one without the other without (at least a moment of) broken state.
That deadlock exists in the process, regardless of whether or not Pact is stopping you.
d
only thing - make can-i-deploy be not fullstopper
but this is scary and make all contract testing useless 😞
A and B are just FrontEnd and Backend
and while there is no continuous deployment - this happens
t
Right, but how is your backend a consumer of the frontend?
d
we have ws messages contracts
so communication is in both directions
but those could be 2 http services as well ( as we have bunch of microservices )
t
Right
So, I think this is the scenario for which you’d need to be able to tell Pact that it’s ok to deploy one without the other
because a WS server that is a consumer is safe to deploy with no clients
However, if your situation is: A and B are already in preprod, but this is a breaking change, then Pact is correctly stopping you from deploying
without Pact, a deploy would induce a broken state
I created this ticket that you can vote for if you like (I also would like this feature, but for a different reason - I have an alternative tool that uses the broker, where a regular HTTP client might be the provider - since it provides requests)
d
However, if your situation is: A and B are already in preprod, but this is a breaking change, then Pact is correctly stopping you from deploying
this could be not a breaking change
just 1 new message/endpoint on each side simultaneously
and - tadaa
so need some rule, which can handle such "big bang"
t
This is a break, right?
Because if you can produce a message that can’t be consumed, then it’s not safe to deploy
and if both sides do that at once, it’s not safe to deploy
I think websockets might be a bit complex, in terms of safety 🤔
What do you think?
I’m not super familiar with them
d
No, it isn’t break
Just 2 features
If they are deployed 1 by 1 ( theoretically in any order) everything is fine
But at once
message has been deleted
😆 3
Exact example all the things
t
yes, that’s what I’m saying - Pact is just telling you that it’s not safe to do that
if you didn’t have Pact, this deployment strategy would let you deploy, but it would be broken for at least a time during that deploy
b
Sounds like the current best solution (which Pact is only indirectly surfacing) is to deploy more granularly.
d
its not possible with release pace
only hack/workaround i found - if pairs A->B and B->A are green I tag one of pacticipants as deployed, then c-i-d says yes
pact cli helps a lot 😄
b
if you have feature toggles, you can still deploy one at a time
I can see how you would get tied up if you're delivering that fast, and not releasing often.
t
Right, yeah. But that hack still results in a broken state momentarily
💯 1
👍 1
d
it shouldnt
if both pairs are green - why should it fail ?
b
Breakage will occur in the window where one is deployed and the other isn't.
t
Why not? If A(v2) depends on B(v2), and B(v2) isn't deployed, it's not safe.
You have a deadlock, regardless of what you do with Pact
👍 2
d
ah, yes, but for now deploys are with downtimes
🤔 1
b
If you're already comfortable with downtime, then this stops being a problem.
👍 1
And I'd say can-i-deploy has reduced value for you, too
👍 1
d
but it will go away soon pepe naruto
t
When it goes away, I think you'll have a problem here too.
💯 1
What you could do, though I haven't thought about this and it might make you nervous when you go to prod, is to make a deploy queue
d
c-i-d has value, as apart from prod version, we have some other long-living version in the wild - apps, and a backward compatibility is very needed
t
where each thing you deployed to dev is put in a queue of deploys
I guess from your original question that you're deploying once per sprint
💡 1
which I'm not wild about, but I see why you might want to do it
d
once per sprint but queue will not help
t
(side note: I have used the sprint number as a version number before - this works nicely if you don't need semver)
d
as again there in queue 2 parts are waiting for each other and we are deploying whole trunks
t
I think the queue would help - because it would just queue the safe path that went to dev
b
It would do a batch of smaller deploys at once 😎 which has some other problems, probably
Well, the deploys are the same size, but the size of change per deploy is small maybe
t
Here's your scenario with queues: • on monday FE(1) as a consumer waits for BE(1) as a provider to be deployed on dev env ( everything is fine ) • on tuesday BE(1) deploys, FE is unblocked -> FE(1) deploys ( still everything is fine ) • on wednesday BE(2) as a consumer waits for FE(2) as a provider to be deployed on dev env ( everything is fine ) • on thursday FE(2) deploys, BE is unblocked -> BE(2) deploys ( still everything is fine ) • on friday we have a release to be deployed on pre-prod environment but got a deadlock hide the pain harold The FE queue contains: FE1, FE2 The BE queue contains BE1, BE2 Queue run: deploy FE1 (no). Deploy BE1 (yes), deploy FE1 (yes), deploy BE2 (no), deploy FE2 (yes), deploy BE2 (yes)
I think this is probably not a good solution, as maybe you never want to deploy FE1 / BE1 to prod
ooh! You could shorten it by going "deploy latest possible deployable"
Which can-i-deploy doesn't have natively, but you could built it on top of pretty easily
what-can-i-deploy
- tells you the latest non-deployed version that is compatible with <environment>
(doesn't exist, but you could build it with a few API calls)
d
thing is on friday we deploy FEnn and BEmm versions , which contains (FE1..FEn) and (BE1..BEm) versions
and we cant get some granular pieces from them
Open in Slack
PreviousNext
Powered by