Hide the new checkout behind a feature flag, turn it on for more users step by step, and roll back by turning the flag off.
Ship dark: the code goes to production but stays switched off behind a feature flag. This is called shipping dark. A feature flag is a switch that turns a feature on or off without a deploy. The code merges to main continuously, instead of living on a long branch. Internal users and QA get it first.
Gradual rollout: increase the percentage step by step: 1, 5, 25, 50, 100 percent. Users are put into buckets by a stable id, so they do not flip between versions. At each step, compare guardrail metrics between users with the flag on and off. Guardrail metrics are numbers that must not get worse:
- JavaScript errors
- checkout conversion
- API failures
- performance from RUM (real user monitoring)
Thresholds are agreed in advance. So the decision to continue is not a judgement call under pressure.
Rollback: turn the flag off. It takes effect in seconds, without a deploy. Problems can also come from code outside the flag. For those, deploys are immutable and versioned, which means a build never changes after release. Rolling back means pointing the CDN or server at the previous build. Old chunks stay available, so open tabs do not hit missing files.
Clean up: after full rollout, delete the old path and the flag. This avoids flag debt: old flags that clutter the code.
- Ship dark behind a flag, and merge to main often (trunk-based development).
- Roll out by percentage, with stable bucketing so users do not flip versions.
- Compare guardrail metrics between users with the flag on and off.
- Turn the flag off for instant rollback, and keep builds immutable.
- Remove flags after the full rollout.
- web.dev (https://web.dev/)web.dev