https://pact.io logo
Join Slack
Powered by
Currently, the proposal is to implement a version ...
# general
a
Currently, the proposal is to implement a version API on each of our microservices and have each service track its required dependency versions and do a runtime or deploy time check to make sure dependency versions are satisfied in the environment. But this is totally sidestepping Pact for dependency management. 😮
t
Can we keep this in a thread, please? Some maintainers/contributors have notifications set for new messages
One challenge with Pact is that it kind of needs your deployment process to be able to be reasoned about
I would ask your infra team how they expect to solve all these problems
This proposed process sounds... scary
a
Sure sorry.
❤️ 1
Yeah agreed. I need to come up with a counter proposal so we don't end up in dependency hell and just use Pact to test compatibility.
💯 1
My thoughts are: 1. Add a check on the PR to update the git state - this could be a Jenkins job or GitHub Action that inspects the change to the declared state and makes the appropriate can-i-deploy check. Not sure if it would make sense to track deployments this way but maybe a GitHub Action could be used for this as well. 2. Pay for pactflow so that they don't have to worry about maintaining the pact broker and it being a SPOF in the deploy process. We already have other SaaS products in the path like GitHub.
t
You can probably present it as a win for the infra team - "hey, we're already doing these contract checks with our CI, you could get deployment safety for free if you integrate it into your deploy pipeline"
yes, #1 feels like a sensible change. You might run into problems though: PR1 updates some consumer version , it's checked compatible with the current provider in prod at PR time PR2 updates some provider version, it's checked compatible with the current consumer in prod at PR time both PRs get merged, and something breaks because the versions in PR1 and PR2 are not compatible.
Ideally you are doing the check right before you deploy.
2. Pay for pactflow so that they don't have to worry about maintaining the pact broker and it being a SPOF in the deploy process. We already have other SaaS products in the path like GitHub.
I don't work for pactflow, but I'd still heartily endorse this as an option to simplify things.
I need to come up with a counter proposal
What I would do is look at the things that pact solves, and then ask how those issues are solved with the current proposal (they're probably not, but if they are, then you can compare eng effort etc). If you have history of your past deployments when you had CD, you might be able to motivate your case with statistics on how often the contracts break
Not sure if it would make sense to track deployments this way but maybe a GitHub Action could be used for this as well.
A github action for can-i-deploy is a great idea, and if you build this it would be totally worth open-sourcing (I reckon @Yousaf Nabi (pactflow.io) would agree)
a
thanks for the feedback!
t
You're very welcome! Let us know how you go
y
Hey hey, Heard my batman call! We do have a can-i-deploy https://github.com/pactflow/actions/tree/main/can-i-deploy Github Action for the Pactflow broker, so it uses a 
PACT_BROKER_TOKEN
rather than a `PACT_BROKER_USERNAME`/`PACT_BROKER_PASSWORD`, it would be easy to tweak for the OSS broker.
a
Thanks @Yousaf Nabi (pactflow.io). Do you also recommend recording deployments and releases with GitHub Actions?
y
Hey it is up to you buddy, Our CLI tools are available in a variety of formats, although the linked page is your bi-directional contracts, a Pactflow only feature, the toolset is the same. https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#installation You can pick whichever is most suitable for your workflow, the GH Actions, is simply a wrapper around the CLI tools, and may be an additional layer of abstraction too far (the CLI tool itself is super versatile) 👍
4 Views
Open in Slack
PreviousNext
Powered by