Roll out new code safely
On the Kubernetes runtime, Runway gives you one rollout gate (staging before production) and one rollout strategy (rolling update). Everything else that makes a release safe is your code’s behaviour behind a feature flag. This page is honest about the first so you invest in the second.
Today, on Runway
What the runtime gives you
- Rolling update. The Deployment uses Kubernetes
RollingUpdateby default (25% surge and 25% unavailable).Recreateis available and causes downtime; Fairway asks you to consult SRE before choosing it. Sources: Runway deployment strategy, Fairway service owner guide. - Staging first. Production renders only after staging succeeds, and you can make the production step a manual play. See Roll a deployment.
- Probes gate readiness. A pod that fails its readiness probe never receives traffic, so a release that cannot start does not take production down. See Check pod health.
What it does not give you on Kubernetes: canary, percentage-based or
regional rollout, health-gated promotion, or automatic rollback. Runway
services run as a single main stage with no canary stage. The Cloud Run
runtime has regional rollout and an error-ratio auto-rollback; Kubernetes has
neither
(
Cloud Run deployment strategies).
maxSurge and maxUnavailable are not yet configurable in Runway v2
(
Migrating to v2).
De-risk with feature flags
Because the runtime cannot do a partial rollout, ship the deployment and the behaviour change separately:
- Deploy dark. New code paths sit behind a flag whose default is
false. The deployment itself changes nothing a user can see. - Turn on in staging, then production. Flags are YAML in the feature-flags repository; Flipt picks up a merged change in about thirty seconds.
- Turn off to roll back. The same MR in reverse. No pipeline, no redeploy. This is the fastest rollback you have, see Roll back a deployment.
- Clean up once the flag has been on everywhere for a release.
The how-to covers each step:
Use feature flags in your service.
The strategy explains the rules behind them, in particular
design for absence:
the service must behave correctly when the flag service is unreachable, which
means defaulting to false.
Use the release gate for what it is for. It protects critical functionality on the way to GitLab.com; it is not where you find out whether your feature works. See What the release gate is for.
On Cells
Rollout policy on Cells (rings, progressive rollouts, maintenance windows) is owned by Tenant Scale and Release Managers, and Theseus deliberately stays out of it. See What Theseus deliberately does not do.