Hey team, I have a question on how to approach

environment

in Pactflow. So at our company, we have a quite a few different environments like dev, staging and production and within each of these, we have sub-env like a few dev farms used by devs, production us production eu. When adding

can-i-deploy

and

record-deployment

we are wondering whether which of these is a better approach: • Create seperate environment that replicates all the envs that we have and ensure that we run

can-i-deploy

and

record-deployment

for each of them • Only check

can-i-deploy

to

production

and

record-deployment

for

production

with the reason being

production

is the final destination in our deployment process so as long it is safe to deploy the changes to

production

that it algood. What are your thoughts on these two. I am leaning more towards the second options since it is simpler and can give us same amount of safety. Thank you 👍

Is it really simpler to have custom config for production only? I would have thought that your pipeline would know which environment it is deploying to, and so it would be “simpler” to have only one pathway (which did the appropriate

can-i-deploy

,

record-deployment

etc)

your pipeline would know which environment it is deploying to

yes it does know which environment it is deploying to. So on branch, we deploy only to development and on master we deploy to development, staging and production

Is it really simpler to have custom config for production only?

so it is simpler in the sense that we would only need to check can-i-deploy once for production cause as long as it works for production, it should give us enough confidence. Otherwise we would need to do can-i-deploy and record-deployment for every single environment when we mainly care about production

Right, but in terms of risk reduction: 1) if you set up the use of can-i-deploy etc incorrectly, then you’d catch it before production. 2) your pipeline will be simpler and safer as it won’t have branches for

if( env == "production")

I am not sure if I get your point on the above but here is how we are setting it up in our pipeline

The point generally is that a pipeline should be a pipeline of steps. Like A -> B -> C -> D. It shouldn’t be A -> B -> if (some condition) then -> C otherwise -> D

for main branch

pact publish

=>

can-i-deploy

to

production

=> if yes,

deploy to all envs

=> once production deployment is done =>

record deployment for production

Yep. I understand. My thoughts are - try not to do it that way if you can avoid it

deploy to all envs

covers our production deployment as well since any merge to master, we would want to keep all envs (dev, staging, and production) up to date

hmmmmm

on branch we only want to deploy our apps to development

This sounds unnecessarily complicated

Usually, dev and staging are newer than production

yeap I get your point. For us though, we got a thing called branch preview so any commit on branch is deployed and any deployed from master to development does not overwrite any of the branch preview - devs can still continue to check their changes on branch preview without getting affected by merge to master

hmm. Is the master deploy the only way to get a main deploy in dev / staging?

yeap same for production

Right, so, from Pact’s perspective dev(main) and staging(main) and production are all “production”

yeah we are still adding

can-i-deploy

to branch to check if it is safe to deploy to

production

- mainly as a sanity check before we merge the branch to master because we don’t want a scenario that pipeline only breaks because can-i-deploy fails in production

What I don’t like about this workflow is that it’s surprising that

dev(main)

and

staging(main)

are actually

production

. But if this is what everyone expects, then I guess it’s fine

dev(main)

and

staging(main)

are

productionish

but no real production traffic is hitting it

eg, front ends, where you know the API isn’t available yet, but you want to get someone to look at it

eg, front ends, where you know the API isn’t available yet, but you want to get someone to look at it

yeah good point thinking2

Personally, in your case (and assuming I’m going for minimal changes to the pipeline), I would: •

can-i-deploy

on main •

can-i-deploy

on PRs to main • no checks on branch deploys

merge queue

you mean only once merge at once and next merge can be done only when deployment of previous is finished?

ah right so we have something similar that there is only one deployment being done at the same time for the same branch

that’s normal

I will check out that merge queue thing

it’s pretty cool

haha yeah I was quite skeptical at first too 😄 so wanted to ask the community to see how others who are more experienced with pact like yourself think

You’re very welcome!

@Viet Anh Tran I don’t have time to read through the whole conversation, but a quick browse of your initial question makes me think that this might be relevant for you https://docs.pact.io/pact_broker/recording_deployments_and_releases#handling-conflicting-views-of-what-an-environment-is

thanks for sharing this Beth 👍. I read through this document and listed it as option 1 above. It feels a bit overkill for our set up so will test out option 2 first and see how that goes