Hi, PactFlow team.
Do you happen to have a _<Reac...
# generalo
Olúwátóósìn Anímáṣahun
05/27/2024, 1:05 PMHi, PactFlow team.
Do you happen to have a _Reaching Pact Nirvana_ equivalent document for a BDCT workflow?
blobwave 1
y
Yousaf Nabi (pactflow.io)
05/27/2024, 5:58 PM
o
Olúwátóósìn Anímáṣahun
05/27/2024, 11:18 PMThanks, @Yousaf Nabi (pactflow.io). I saw that page earlier but I don't think it clarifies (extensively) what should happen once breaking changes begin to set in. I'm referring to merging and the automation of builds and deployments.
> Please note that we already have Pact/PactFlow operations built into our CI/CD pipelines for both provider and consumer.
>
> These operations include:
> • Provider:
> ◦ Build & Test
> ◦ Publish OAS
> ◦ Run Can-I-Deploy
> ◦ Deploy
> ◦ Record Deployment
> • Consumer:
> ◦ Build & Test
> ◦ Generate & Publish Pact
> ◦ Run Can-I-Deploy
> ◦ Deploy
> ◦ Record Deployment
To my questions...
When a provider changes:
• Should the provider be blocked from merging to _main_/_master_ until the consumer(s) has updated their code?
• Should the provider continue to retry their can-I-deploy (indefinitely) until it passes -- i.e., while waiting for the consumer(s) to be aligned?
On the other hand:
• Should the consumer do the same if they've updated their pact tests much quicker -- before the provider implementation is done?(Recall it's design first; so either pacticipant could finish their implementation faster.)
---
Also: Our CD deploys to a lower environment (e.g. "DEV") on merge to _main_/_master_. This means that if a pull request is merged from a provider before the consumer(s) is updated, then the CD would fail. So:
• Should a PR be merged only on the condition that can-I-deploy passes?
Olúwátóósìn Anímáṣahun
05/29/2024, 2:03 PM@Yousaf Nabi (pactflow.io), @Matt (pactflow.io / pact-js / pact-go): ICYMI, I updated my question above.
Olúwátóósìn Anímáṣahun
05/31/2024, 1:14 PMI'm currently stuck, and I hope one of the PactFlow team members can really brainstorm with me here. I have some ideas but would like to validate my thinking.
For example, am I running into this scenario because my provider has introduced a backwards incompatible change suddenly?
> Context: We have both pacticipants within easy reach -- think microservices. So, it's easy for us to make this kind of sudden changes.
I can imagine that if changes are more carefully introduced, allowing time for deployed consumers to continue to be supported (for some time -- think deprecation) as new changes are gradually rolled in, then, I might not even run into the issue I am describing here.
I'm at a crossroad: Both provider and consumer now have open PRs, but neither can be merged because Can-I-Deploy fails on each one's pipeline. In each case, it's checking what has been deployed for the other pacticipant.
I've pored over several docs and even searched lots of historical conversations in here but don't see an answer.
In most cases, the docs largely assume a consumer driven approach, including the CICD guide here: Diamond level | Pact Docs
From what I see, the guide only goes as far as the first set of successful deployments (which we have also done). But it doesn't address changes that come afterwards, and how to coordinate this.
m
Matt (pactflow.io / pact-js / pact-go)
06/02/2024, 10:45 PM
Sorry I missed this @Olúwátóósìn Anímáṣahun.
For example, am I running into this scenario because my provider has introduced a backwards incompatible change suddenly?yes, pretty much. I guess we could have an article about this in PactFlow, but it’s no different to the answer here: https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider That is, don’t push a breaking change to the provider and expect the tooling to easily resolve the situation. Most people will configure their setup (like you have) to prevent deploying / merging things that will break. Either follow the expand and contract pattern (described/linked in the above reference) or manually override parts of the pipeline to allow the breaking change through temporarily.
Matt (pactflow.io / pact-js / pact-go)
06/02/2024, 10:46 PM
FWIW even at PactFlow, we have a way to skip Pact tests if needed to get out of a bind
o
Olúwátóósìn Anímáṣahun
06/03/2024, 5:44 AMThanks for your reply, @Matt (pactflow.io / pact-js / pact-go). I had a thought over the weekend, and this pretty much gives me the nudge in that direction.
It's somewhat a reverse of what that link proposes -- perhaps because we use BDCT and are provider driven.
Basically, I was thinking of this:
1. temporarily skip/ignore*** affected tests in the consumer;
2. merge breaking change from provider; then,
3. make subsequent merges to fix the consumer (i.e., bring the tests up to date).
Hopefully, we can come up with a neat way to automate most steps in this process.
***Note that skipping tests is a feature in some testing frameworks.I also think this would be easier than the traditional expand and contract, in that, sometimes, it might be tricky to implement a breaking change alongside old features.
m
Matt (pactflow.io / pact-js / pact-go)
06/03/2024, 7:07 AM
Yep, something like that would work. The issue is that you will need to time your releases to happen at the same time - otherwise there will be a period where the API is in prod that is not compatible its with consumer(s). This is why expand and contract is better, but YMMV
👍🏾 1
o
Olúwátóósìn Anímáṣahun
06/03/2024, 9:01 AM@Matt (pactflow.io / pact-js / pact-go): Certainly. But since we'll be coordinating this with all parties fully aware, it should not be a problem.
👍 1
21 Views