DevOps
Rolling Updates
Replace instances with the new version a few at a time so the service stays fully available throughout, with health checks gating each step. It is the default zero-downtime strategy in Kubernetes and needs no extra environment. The trade-offs: two versions coexist mid-rollout, and rollback is slower than blue-green's instant flip.
Purpose
A rolling update replaces instances of the old version with the new a few at a time — take one out, start the new, wait for health checks, repeat — so the service never drops below capacity. It is the zero-downtime strategy that needs no duplicate environment.
When to Use It
The default for orchestrated fleets: Kubernetes Deployments roll by default, as do cloud instance groups. It suits routine releases where the risk profile does not demand a canary's gradual traffic gating.
Trade-offs
Old and new versions serve traffic simultaneously mid-rollout, so API contracts, message formats and database schema must be compatible across the pair. Rollback means rolling forward through the fleet again — slower than blue-green's instant flip. Bad health checks let a broken version march through the whole fleet.
Implementation
In Kubernetes, tune maxUnavailable/maxSurge and — decisively — configure real readiness probes: an instance receives traffic only when genuinely ready, and the rollout halts when instances fail. Drain connections gracefully on shutdown, and pair with expand-then-contract schema migrations.