branch based commerce environment

[npeltier]

Commerce techies know this, depending on commerce tides, we may want to point pages to stage commerce system, and we may want another dimenstion which is landscape to use "draft" rather than "published".
Another aspect is we want at the same time all the flavours of those 2 configurations, because at the same time we need to validate similarity to production, new commerce feature A, and new commerce feature B.
while we could add some query params to hack that up, i guess it could be easier to just agree on a naming convention of branches and end up a branch with something explicit like commerce_stage or commerce_draft that would basically be stage env (no landscape) or production, landscape = draft.

wdyt?

[3ch023]

I like the stable branch idea, but IMHO we should name them something shorter.
e.g.

• 'main' - already exists, so no need for wcs_prod (WCS: prod, landscape: PRODUCTION)
• 'wcs_draft' (WCS: prod, landscape: DRAFT)
• 'wcs_stage' (WCS stage, landscape: 'any')

[npeltier]

ok, but may be if wcs_(draft|stage) is not found in branch name, we just use prod environment & published landscape. This way "main", and all other branch names use the later.

[drew-cottrell]

If 'wcs_stage' is (WCS stage, landscape: 'any') how will one know if they're getting draft or published data? Just trying to wrap my head around all the permutations here: https://developers.corp.adobe.com/aos/docs/guide/overview.md#dataplanes

[npeltier]

there is no draft/published landscape in stage, in other words you should consider offers to be equivalent between stage & production draft.

[npeltier]

one thing this does not fix though is the ability to test promotions days in advance, unless we decide to create a special PROMOTION_wcs_draft branch for that matter

[3ch023]

I thought 'wcs_draft' will cover that

[npeltier]

we could, yes

[yesil]

@npeltier are we talking about Milo branches? Is this going to affect Dexter environment in any way?

[3ch023]

i think its milo only, yes

[npeltier]

yes!

[yesil]

@npeltier why not add an optional query param to switch environment + landscape.
Thus we can test it on all the active branches.

https://main--milo--adobecom.hlx.page/drafts/ilyas/merch?cEnv=stage-ALL

[npeltier]

that's an option, but i wonder if that would work with indirections in multiple page validation processes, where one would have to add parameter, then refresh page...not ideal

[yesil]

maintaining branches is also a tedious job, I would avoid it at cost.

[npeltier]

i guess you mean at all cost. If you refer to maintaining code fresh in our non standard branches, as this would strictly be fast forward, we could probably automate it somehow.
The other side is hacking around code to propagate parameters, which in my opinion is worse.

[3ch023]

The other side is hacking around code to propagate parameters, which in my opinion is worse.

I know you joked about it earlier, but indeed some simple chrome extension must be able to add a param automatically to each loaded URL.. i don't think we need to make an effort in code

[npeltier]

discussed with @3ch023 and we agreed to go for query parameter approach for now as it's the simplest. I'm still not entirely bought to drop branch based for bigger QA efforts that implicate multiple page browsings but we'll seen when it happens

[3ch023]

ticket: https://jira.corp.adobe.com/browse/MWPW-140470