Hi there, I have a question. What should we do wh...
# pactflow
s
Hi there, I have a question. What should we do when we have both applications are consumer and provider at the same time?
m
contract test them 😉
😂 2
🍌 1
What’s the actual problem you’re trying to solve? It’s totally normal for that situation to happen
s
Let's say which one should we deploy first? Asking about the best practices in this case?
m
Ideally you don't have to worry about sequencing changes. Why is this a perceived problem? Ideally, you make a change to an application and deploy that, and not worry about dependencies (Pactflow will tell you if you're going to break one)
But obviously, if a consumer needs a new API then the provider needs to go first (or you feature toggle the consumer)
a
Hi @Matt (pactflow.io / pact-js / pact-go), thanks for your reply. The problem Saleh is talking about is the following: We have two applications, and both of them are a consumer and a provider at the same time. There is a circular dependency.
Copy code
(Consumer) A -> B (Provider)
(Provider) A <- B (Consumer)
Thus, we can’t deploy app A (consumer), because it require app B (provider) in place and vice versa. Am I understanding it correctly, the only way to resolve this is feature toggles? Thanks in advance.
👍 1
m
Well you just need to get one of the apps deployed initially to break the cycle, and then you just need to not get into a situation where they both have changes that depend on one another (because Pact aside, this is an awkward situation to be in!)
Is there something you're stuck with or is it theoretical?
a
Hi @Matt (pactflow.io / pact-js / pact-go), Thank you for your reply. Unfortunately, no, it’s not theoretical. We are facing the dilemma exactly like this. So, it seems to me that every time we have such a conflict, we have to skip
can-i-deploy
step. 1st scenario is initial deployment, when none of the apps (A or B) is deployed in an environment. In this case we have to skip
can-i-deploy
step for the app, which is deployed first. 2nd scenario, when both of the apps are depends on newer versions of each other, for example: • A version 1.0 is deployed on dev env. • B version 1.0 is deployed on dev env. • A version 2.0 depends on B version 2.0. • B version 2.0 depends on A version 2.0. So, in this case we’ll have to skip
can-i-deploy
for one of the apps (A or B) as well, which is deployed first. Am I missing something?
m
So assuming you weren't using Pact, what would you do? Building software that has circular dependencies like this where each change requires both sides to update simultaneously is not ideal - now you have no choice but to deploy them together
You might then argue the boundaries are wrong and they in fact shouldn't be two separate systems
If you want to use can I deploy, you'll need to make changes in such a way that you can deploy one independently of the other i.e. change only one thing at a time
What's the specific use case that's causing the need to change both at once?