https://pact.io logo
#general
Title
# general
d

David Van Couvering (DVC) - eBay

02/09/2022, 12:55 AM
Hey. I was watching the

AMA on pending pacts

and @Beth (pactflow.io/Pact Broker/pact-ruby) said the recommended approach is for the consumer to code against new functionality on a feature branch so it doesn't break the provider. I totally get why this approach solves the problem of not introducing a contract into the main branch until it's ready to go live. However, this pretty much goes against trunk-based development. This is a key practice that has been shown to improve software delivery performance (see the book Accelerate). For reference you can see the DORA page on trunk-based development as well as https://trunkbaseddevelopment.com/ It's great that pending pacts helps solve this, but I am concerned in general that as you develop tools and features for Pact, you're assuming a workflow that actually isn't best industry practice these days. For example, an important workflow we need to support is to put new changes behind a feature flag. We want to test the new pact that's behind this feature flag without causing the provider to have their build break now that the pact has been verified (which is what would happen with pending pacts). I think we can do this with tags (need to try it) but I'm concerned you're moving away from tags to the concepts of branches, deployments and features. In that world, there is no space for scoping a pact and its verification based on a feature flag. I'd love to hear your thoughts on this. Thanks!
🙌 1
b

Boris

02/09/2022, 1:02 AM
There are a few flavours of trunk-based, the one I see most often is very short-lived feature branches. I think might be the best-practice assumed workflow, or you need compile-time feature flags to not break the trunk.
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:03 AM
Yeah, even the guide above has PRs that are attached to a branch (and, if not a branch, something conceptually identical to one)
that being said, you’re on the mark and we are thinking of ways to incorporate feature toggles into this workflow also
party parrot 1
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:04 AM
Yea, but those are short-lived branches, like a day. In teams that are really good about delivering functionality in small chunks, an API change could go out in a day. But in other teams/orgs this is not the case, and generally the consumer will want to push out their changes even while the provider is still working on their side.
👍 1
Feature toggles is an example; my point is that the recommended workflow for Pact is going against the grain of very short-lived feature branches
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:06 AM
I don’t think Pact takes a position on the lifetime of a branch, but perhaps you’re suggesting as a result of having branches as a concept it might result in longer-lived branches as a consequence?
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:06 AM
Long-lived feature branches are really problematic; this is not just theoretically true, I still have scars on my back from teams that have done this
💯 1
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:06 AM
haha yes, most of us have!
😅 1
💯 1
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:06 AM
I don't see how you can recommend keeping a new API change on a branch without it becoming a long-lived branch
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:07 AM
right, in that case you can definitely toggle (I do think we have some docs on that).
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:07 AM
Oh that's great. I couldn't find any
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:08 AM
Haha thanks. Sometimes search just doesn't work
But, are tags going away as a thing?
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:09 AM
no, I don’t think we’re looking to remove them
I would expect, at some point, a concept like a feature toggle to make its way into the broker so that they can be incorporated into standard workflows as a first class citizen though
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:10 AM
Ok, well that's good. I think I've made my point and I will stand down 🙂 Realizing, reading your docs, that the same git sha is actually different versions of the consumer depending on which set of flags are toggled on or off. 🤔
Yea I do prefer first-class concepts over a bag of tags
💯 1
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:10 AM
bag of tags
🤣
On the docs above, it’s possiblre there are better ways that advised. If you come up with them, do let us know - it’ll help with any future feature support and of course, docs
👍 1
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:12 AM
Yea, it's actually an incredibly common anti-pattern. A developer says "we don't know what the schema is, so we just implemented a table with key column and a value column. It's so nice and flexible!" I go 😱 and explain the problem with what I call a "bag of flags"
👍 1
m

Matt (pactflow.io / pact-js / pact-go)

02/09/2022, 1:12 AM
Yes, it’s also “very flexible” - what could be bad about that?!
d

David Van Couvering (DVC) - eBay

02/09/2022, 1:12 AM
b

Boris

02/09/2022, 1:18 AM
yeah, "bag of tags" is usually a workaround for "we don't know what we/you want/need yet" 😅
3 Views