Overlay Program · Process Definition
Two mechanics run underneath every stage: code promotion (how a change physically reaches an environment) and feature exposure (whether that change is switched on for anyone). They are independent, and that separation is what makes the whole process work.
Core rule: a user only sees the new overlay when both configs are on. An overlay being deployed and an overlay being visible are two different facts: the Angular side has its own config for whether it renders the new modal instead of the old one, and Hybris has its own config for whether it dispatches the trigger event at all.
Ticket split: four ticket types cover an overlay end to end, because analysis, the two codebases, and cleanup are each a separate piece of work:
| Type | Tickets | Why |
|---|---|---|
| Hybris | 1 — business-rules analysis | Documents what the legacy overlay actually enforces today, before any code is written, so the Angular build replicates the real rules instead of guessing at them. |
| Angular | 2 — implementation, then integration | Building the new overlay and wiring it into a given page are treated as separate pieces of work. |
| Hybris | 1 — trigger / config, only if Hybris-triggered | Removing the old trigger and dispatching the new event is the same code change, not two. Skipped when the overlay is triggered from a page already on Angular (PDP, PLP, Joblist, Configurators) rather than one still served by Hybris (Cart, Checkout, Homepage, transversal concerns like session timeout). |
| Cleanup | 1 — retires the legacy path | Filed once the overlay is fully validated and stable everywhere (see Maturity & cleanup); removes the legacy modal and the config. |
This defines what ticket types exist and why — not which tickets exist for which overlay today. That's tracked operationally on the Spring Overlay Coverage page.
How an overlay is tested and signed off end to end, from Build through QA, UAT and Production, broken out by who's holding the ticket at each step.
End-to-end on QA. Both the Angular and Hybris overrides described in Activation logic need to be exercised together so the overlay can be tested end to end on QA — making sure both are in place is QA automation's job.
Handoff into prod. Once the automated suite passes on every UAT banner, QA automation reassigns the ticket back to the developer who built it, and they release it to prod. Once it's live, the PO runs a sanity check and QA automation runs NRT.
Rollout order: same Sweden-first shape as UAT, then the rest of the banners follow under two production-specific constraints:
Country testing at activation is FYI, not a gate. Before an overlay is activated for a given banner in prod, that country can test it live if they want — using the same URL-parameter override, without touching the shared config — but there's no required approval step. Overlays needing country-specific input (content, wording, local nuance) get that during discovery instead, not as an activation gate.
Rollback is symmetric with rollout. Because the config is just an environment variable, turning it back off is just as instant as turning it on — a bug or blocking issue in production reverts to the old modal immediately, with no code change and no deploy.
Cleanup trigger: once an overlay is fully validated and stable across every banner, the config goes away entirely. The config exists to let old and new coexist safely in the meantime, which means the code carries both versions behind a conditional indefinitely by default. A cleanup ticket is what actually retires that: it removes the legacy modal code and the config, leaving the new overlay as the only path.