Progressive Rollouts
Release to a small audience first, protect your customer experience, and expand with evidence.
Release with less risk
- 1.Validate internally
- 2.Expand in stages
- 3.Keep a rollback ready
A release should not be an all-or-nothing bet. Put your next feature behind a flag, expose it to a small audience, and use real production signals to decide when to expand. You can change exposure without waiting for another code deployment.
When this helps your business
- Protect the customer experience: limit the audience exposed to an unproven change.
- Keep delivery moving: deploy the code separately from the decision to release it.
- Make launches accountable: agree on error, latency, and conversion thresholds before increasing exposure.
Flags reduce exposure; they do not replace testing, monitoring, or a database rollback plan. Choose a feature where the previous experience can remain available.
Set up your first controlled rollout
1. Keep the current experience as the fallback
Create a boolean flag such as new-checkout in the environment used by your production app:
| Setting | Value |
|---|---|
| Variation 0 | true — new checkout |
| Variation 1 | false — current checkout |
| Default variation | 0 — for users included in the rollout |
| Rollout percentage | 0% — no general-audience exposure |
Integrate your SDK, initialize it, and supply a stable userId in the context. For an initialized JavaScript client:
if (client.isEnabled('new-checkout', false)) {
showNewCheckout()
} else {
showCurrentCheckout()
}
Use false as the fallback while configuration is unavailable. For React, the Feature component can keep the current checkout visible while the provider loads.
2. Validate with your team
Keep the general rollout at 0% and add a targeting rule that returns variation 0 for a trusted internal-user attribute supplied by your app. Check both an internal user and an ordinary customer.
Targeting rules run before percentage rollout. Internal users can see the feature while everyone else stays on the current experience.
Do not rely on a flag for permissions. Use trusted context values and enforce protected actions on the server. If you use encrypted target lists, follow the crypto adapter setup.
3. Open a small canary
In the production environment, increase the general rollout to 1% and save. With a stable user ID, cohort membership is deterministic for that flag rather than changing on every visit.
Monitor your application analytics and observability tools:
| Signal | Decision it supports |
|---|---|
| Error rate and checkout failures | Is the new path reliable? |
| Latency and dependency load | Does it behave under real traffic? |
| Conversion and completed purchases | Is the customer outcome protected? |
| Support tickets and feedback | Are users hitting unexpected friction? |
Flag-evaluation analytics show usage, not completed purchases or customer satisfaction. Instrument those outcomes separately.
4. Increase only when the evidence supports it
An example sequence is 1% → 5% → 25% → 50% → 100%. Treat it as a review plan, not an automatic schedule.
Choose observation windows based on traffic, risk, and the business cycle. A low-traffic checkout may need longer than a busy page to reveal a meaningful change. Assign an owner who can pause or reverse the rollout.
Prepare the rollback before launch
To return general-audience users to the current checkout, set the rollout to 0%. Also change or remove any targeting rules that still return true; matching rules bypass the percentage.
If you use a separate kill-switch flag, check it before entering the new code path. See kill-switch patterns.
Updates take effect after the configuration is published, fetched by the SDK, and reflected in your app. Polling, caching, and connectivity affect that timing; do not assume an instantaneous rollback. Test the fallback and change subscription behavior before relying on it.
Flag changes cannot undo database migrations, sent emails, or payments already processed. Keep those recovery procedures separate.
Finish the release without leaving cleanup behind
Once the rollout is healthy at 100%:
- Remove internal-only rules after confirming the new experience is correct for everyone.
- Deploy code that no longer depends on this release flag.
- Wait until no supported deployed version uses the flag.
- Archive the flag and remove unused targeting lists.
Keep long-lived operational kill switches separate from temporary release flags.
Ready to launch?
- The new and fallback paths work in a non-production environment.
- A stable user ID is supplied and internal/non-internal users receive the expected values.
- Someone owns the rollout, with agreed metrics and pause criteria.
- Rules and rollout percentage have both been considered in the rollback procedure.
- Configuration updates reach the application and refresh the experience as expected.
- The team has a cleanup date and a recovery plan for irreversible actions.
Continue your release plan
- Beta testing — collect feedback from an invited audience.
- Rollout concepts — understand cohort membership and rule precedence.
- A/B testing — compare experiences when the question is impact, not just reliability.