Rolling Deployment

A rolling deployment introduces a new application version across a fleet in successive batches. Some instances, tasks, or pods continue serving the previous version while others are updated or replaced. After each batch becomes healthy, the deployment proceeds until the fleet runs the new version. The defining characteristic is gradual change to the serving fleet, not a specific cloud service or deployment tool.

For example, consider a web application running on ten virtual machines behind a load balancer. A deployment process removes two machines from traffic, allows active requests to drain, updates their application, validates readiness, and returns them to service before continuing. The remaining eight machines must handle demand during each batch. Alternatively, the process can launch replacement capacity before removing old machines, increasing temporary cost while preserving serving capacity.

Batch size, minimum healthy capacity, maximum total capacity, startup time, and observation periods determine deployment speed and availability. Small batches reduce the number of resources affected simultaneously but lengthen the rollout. Large batches finish sooner but expose more capacity to a defective release. A successful process checks application readiness and operational signals such as error rates and latency, rather than assuming that a running process is ready to serve users.

For virtual machines, rolling deployment can update application files on existing machines or replace machines using a new image or launch template. AWS CodeDeploy supports batched in-place deployments for EC2 applications. Amazon EC2 Auto Scaling instance refresh progressively replaces instances. These mechanisms solve different problems: deploying application artifacts does not necessarily update the machine image, and changing a launch template alone does not update existing instances.

For containers, an Amazon ECS rolling deployment replaces service tasks according to configured minimum healthy and maximum deployment percentages, subject to available capacity and health checks. Kubernetes Deployments, including those running on Amazon EKS, control replacement pods with maxUnavailable and maxSurge. Readiness probes determine whether pods should receive traffic. A Kubernetes rollout that exceeds its progress deadline is reported as failed; the Deployment controller does not automatically roll it back merely because that deadline expires.

Old and new versions normally coexist during a rollout. APIs, message formats, shared caches, and database schemas must support that overlap. An expand-and-contract database migration can add a new field first, deploy code that supports both schemas, and remove the obsolete field only after old versions are gone. Rolling back application code does not automatically reverse database changes, external side effects, or incompatible messages.

Rolling deployment differs from blue/green deployment, which prepares a separate replacement environment and then switches traffic. It also differs from canary deployment, which deliberately exposes a new version to a limited audience or traffic share for evaluation. A rolling deployment's first batch can provide early feedback, but resource batch size does not guarantee an equivalent percentage of requests. Load balancing, connection reuse, and session affinity affect actual exposure.

Serverless deployments require different terminology. AWS Lambda deployments typically publish versions and shift an alias between them using all-at-once, canary, or linear traffic shifting. Linear traffic shifting is gradual, but it is not replacement of customer-managed hosts in rolling batches. In exam scenarios, distinguish the desired outcome from the platform's supported deployment mechanism.

Rolling deployment does not inherently guarantee zero downtime or automatic rollback. Pipelines must define validation, stop conditions, alarms, and recovery actions supported by the deployment platform. Recovery may require another gradual rollout of the previous version, so retain deployable artifacts and allow enough capacity for both deployment and recovery.