M@S2 Release & Consumption Model

[3ch023]

This is to discuss how to organize the release and consumption model of Merch artifacts in M@S2.

At the moment Milo loads the latest commerce.js and merch-*.js files, and with M@S2 we intend to keep it similar, even if files structure is subject to change. Versionless & always up-to-date will be the default consumption model.

However, some of the other consumers of Merch Artifacts are having use-cases where versions might be required.
With the web, there is only 1 version of consumer code (e.g. Milo) that's live.
With applications, there could be multiple versions for multiple devices of consumer code (e.g. CCD) that are live. And amount of those versions live could make release verification step complicated since:

1. it is too many versions to be included in the testing scope
2. there could be at some moment such a big implementation difference between versions, that will make it impossible to consume latest artifact.

Let's share our options in the comments and discuss each version separately, understanding pro's and con's

[3ch023]

Option 1.

adobe.com/mas-*.js by default are all versionless and follow the usual milo release lifecycle.

On-demand, consumers could use a special release workflow that will release from the feature branch /mas-*.js artifacts to a specific folder. e.g.: adobe.com/27.08.24/mas-*.js or adobe.com/1.4.0/mas-*.js

[npeltier]

or some private place from where that file is pulled at build time

[3ch023]

right, it's not bound to CDN serving JS (although it is probably the easiest option).
It could also be an NPM package in the artifactory or something else.

[mokimo]

here's some recent feedback had about versioning for the universal navigation. It was a clear no from @narcis-radu and myself #2741 (review)

IMO stay evergreen and if you have breaking changes - just ship those upgrades in one go and instantly deprecate the old version.

[mokimo]

There are several ways to avoid breaking changes:

• Opting into new breaking features with a feature flag
• Deprecating a feature and then remove it, after consumers migrated
• Adding a compatibility layer to ensure non-migrated consumers don't experience interruptions

[3ch023]

yes, but breaking change is only one of the concerns.

the bigger problem is the cost of test automation (+manual validation) for each of those versions.
I just wonder if we should risk and try it or not..

[npeltier]

the option "no we don't do versions" is still one, but as @3ch023 stated it, we have here quite specific consumers with much wider compatibility gaps (e.g. windows 8's chromium).
The different ways you mention @mokimo are great, but the more "hidden versions" you swallow with those tricks, the more fat and complex you get, and imo there is a threshold above which we'd better manage separate files (not saying here it's over it, still under evaluation)

[npeltier]

There is also option for application to become a build dependency, while keeping on deploying evergreen artifacts: pure commerce is less likely to change overtime, and we don't have to manage one huge dependency growing with the consumption (and the history of it).
So our web components would be pulled as versioned build artifact(s) at CCD build time, that point to commerce runtime dependency. HEAD state would be deployed as runtime dependency for other consumers.

[3ch023]

'application to become a build dependency'

I am afraid I didn't understand it, what is 'application' in your example?

[npeltier]

sorry i'm using application to differentiate that kind of consumer from a browser consumer. Our only application consumer atm is CCD, that has a build process in which it could pull versioned web components from us it needs.

[3ch023]

So far I am leaning toward evergreen as an initial integration option.

[npeltier]

this needs solid validation process (one DNA based validation page with all usages per major version i'd say)

[3ch023]

thats true but i have a feeling we will be more stable and safe from CSOs with 1 version rather than n of them.

[3ch023]

Refreshing this topic.
While discussions with consumers continue, it becomes more and more likely that we will need some version mechanism for merch JS files.
I would like to open a discussion where we could put those.
Would the GitHub repo be an appropriate location? Need some feedback from community here.
E.g. we could have a GitHub Action creating a version folder near the evergreen file (https://main--milo--adobecom.hlx.live/libs/deps/mas/mas.js) so that you have

• https://main--milo--adobecom.hlx.live/libs/deps/mas/{{version}}/mas.js
• https://main--milo--adobecom.hlx.live/libs/deps/mas/mas.js

The idea is to create a version only when required (maybe even a self-service for a consumer, from the main branch code)
WDYT?
The advantage here is that all versions are easy to find and have an akamai proxy by default.
Disadvantage maybe growing repo size, although I'd assume files won't take much.

[mokimo]

Version maintenance becomes complex and a testing dependency. If you can avoid it, that'd be my suggestion 😬

[mokimo]

Another piece of real world feedback from Fred, he's strongly advising against versioning given the overhead that it brings with it.

[3ch023]

We would also need the ability to release from a hotfix branch, not just the main.

Having versionned mas.js in the repo will keep the main branch grow, and pollute the search experience in VSCode.

yeah, this is a valid point.
I am also fine with GitHub releases. But one thing I am not sure about is why would we release on each merge? in that case we have 15 versions, only 3 of them ever used. We could have a release when it's required, no?

[yesil]

Depending how we decide what is a mas release, we can optimize the number of releases.
Automated release has the advantage of deciding versions numbers based on the semantic commits, otherwise we would have to invent our own version numbers.

[mokimo]

+1 on semantic commits & semantic release or equal if you go with npm versions. U'd likely need to adapt the thing a bit since we are in a monorepo and would only want releases for MAS and not general milo commits