https://pact.io logo
Join Slack
Powered by
Hi, I have a question about implementing Pact. I h...
# general
r
Hi, I have a question about implementing Pact. I have been investigating Pact as a POC for a multi team project where the Consumer and Provider teams will be separate. I have created the POC following the best practice for CI/CD as described in the Pact documentation. There is one thing that I think will be a blocker for us to implement Pact and contract tests which is that the necessity of the Consumer code creating (or updating) the the contract first means that this work done by the Consumer team is left in limbo - it cannot be merged into the main branch and must be shelved until the Provider team 'get around' to fulfilling the contract. Under our definition of done this leaves that piece of work incomplete, and dependent on another team before it can be completed. We have tried to remove dependencies like this between teams as the teams are not always at liberty to drop what they are currently working on and so it may be some time before the provider work is done, leaving the Consumer code going stale on a branch. For reference the current process would be that the Provider team would develop the interaction first, test and merge to main, completing their story. The Consumer team could then implement the usage of the feature with no dependency on the Provider team. I would be interested to hear if others have faced this and how they have addressed it or what would the recommended approach be?
t
Under our definition of done this leaves that piece of work incomplete, and dependent on another team before it can be completed.
How would you solve this problem without Pact?
For reference the current process would be that the Provider team would develop the interaction first, test and merge to main, completing their story. The Consumer team could then implement the usage of the feature with no dependency on the Provider team.
Er. For equivalence, wouldn’t you say that the provider team can’t complete their story without the consumer team doing theirs?
I mean, what happens when (inevitably) it turns out that the provider team made a mistake or the consumer team need more information in a response than they realised?
I’m suspicious of a definition of done that lets one team mark a bit of work as done before the other team have validated that it works for them.
what would the recommended approach be?
Pact is, by nature, consumer driven. This is definitely the recommended approach. The server exists to, well, serve. So, the ideal design process is to have the consumer tell it what they need.
Where I’ve been forced to do something from the provider side first, my experience is that the overall implementation time (to get end-to-end working) is longer, less likely to be a well-designed API, and requires more rework
A related question that might be worth raising is - if your teams are this dependent on each other, why are they separate teams?
If you’re just trying to make sure that teams are not blocked, what I have found successful (and facilitated by Pact) is: 1) Consumer team writes the Pact 2) Provider team adds the verification to their backlog 3) Consumer team proceeds with mock responses (not even hitting any API) safely, since the mock responses can be exactly what the expected response was in the Pact 4) At some point, the provider team finish the verification, and you can use the real endpoint. This works really well for APIs that aren’t complex, or are a lot of read-only requests. Your milage may vary.
Under our definition of done
What is this definition of done? I’m concerned that a consumer team wouldn’t be done without the provider team’s work, but the provider team can be done without the work of the consumer team. If either one of the teams haven’t done their bit, then presumably value is not ready to be delivered to users?
Really, it seems to me that there’s a process problem that is unrelated to Pact.
this work done by the Consumer team is left in limbo - it cannot be merged into the main branch and must be shelved until the Provider team ‘get around’ to fulfilling the contract.
This is true in your usual approach too, yes? It’s just not exposed, because the consumer team don’t even start the implementation while they’re waiting for the Provider team to ‘get around’ to building the endpoints.
b
leaving the Consumer code going stale on a branch
Feature toggles are usually used to address this, so the work can be "done" while not finally exercised, and not go stale on an old branch. I think Pact either has support for feature toggles now, or it's being worked on.
Apart from that, I agree with Tim that this isn't really a Pact problem, but it might be highlighting other issues 🙂
3 Views
Open in Slack
PreviousNext
Powered by