A Release Process for Standalone Gnav

[sharmrj]

Milo "releases" (so called because technically Milo/EDS do continuous delivery but we have a staging process) fairly quickly, too quick for most standalone gnav consumers. We need to have a release process for changes in standalone gnav. The ersatz solution is to maintain two separate branches from main, called stage-feds-gnav and feds-gnav, and every two weeks merge main into stage-feds-gnav and then stage-feds-gnav into feds-gnav.

We'll have an Akamai rule that redirects any requests going to www.adobe.com/feds-gnav/ to feds-gnav-milo--adobecom.hlx.live/libs/ (by the same token, requests to www.stage.adobe.com/feds-gnav/ go to stage-feds-gnav--milo--adobecom.hlx.live/libs/). This way standalone gnav consumers will be able to access a slightly stale, but safe version of the code while still hitting www.adobe.com for the Gnav.

related PR: #3113

[mokimo]

I would discourage getting into versioning and stay evergreen. If you really want/need/have to do versioning, I'd strongly recommend doing proper releases similar to mas as seen here - rather than akamai magic and living in separate branches.

We should stay consistent in the approach within the repo. There are similar discussions for mas that happened

[sharmrj]

I agree on the general principle. Akamai magic is not ideal. We discussed something similar to the mas strategy in that we thought about creating a bundle, and that option remains a bit underexplored given our tight deadlines. I worry about how deeply embedded gnav is in the Milo context, but I can try spending a few hours on a POC.

@salonijain3 @bandana147 opinions?

[mokimo]

Maybe you can sync with @yesil or @npeltier who deliver this to the same consumer, to learn about how they handle this.

[bandana147]

@mokimo I agree that depending on Akamai and a separate branch is not ideal, but bundling isn’t currently feasible without significant changes to the current milo implementation.
We conducted a POC before settling on the current solution; Milo's code depends heavily on dynamic imports based on origin and environment, which makes bundling challenging without altering Milo's structure. However, if there’s an approach we can take to make it bundleable, I’m open to exploring that further.

@amitbikram @salonijain3

[mokimo]

Related discussion https://github.com/orgs/adobecom/discussions/2792

[overmyheadandbody]

Fully agree with @mokimo, there's already an established pattern for such use-cases, that would likely be the better path. Special branches + Akamai rules sound quite non-transparent, which we want to avoid.

[sharmrj]

@overmyheadandbody @mokimo We could get this in as a temporary solution so we can make it by 11/12, and then have another ticket for implementing a better approach (a bundling approach) after that. Would that be acceptable?

cc: @salonijain3

[mokimo]

If you have a tight deadline to hit that's okay and a follow up would be greatly appreciated.

There are several pitfalls with the current implementation which justify spending the extra time:

• Only one concurrent version
• Opaque solution with the branch/akamai path matching, without prior context
• Deviates from a platform solution and can't be reused (See MAS solution or the libs/deps approach)

[salonijain3]

@mokimo @overmyheadandbody

We will be going with the bundling approach targeted for 3/12 rollout.
Initial PR raised : #3132

cc: @sharmrj @bandana147 @narcis-radu