Rolling Deployments
18 min
A rolling deployment updates a fleet of instances in batches: take a few instances out of rotation, update them to the new version, bring them back, then move to the next batch — until every instance is on the new version. Unlike a canary rollout (which keeps both versions running side-by-side while shifting a traffic PERCENTAGE), a rolling deployment is a one-way march toward every instance running the new code, with no ongoing traffic split once it finishes.
def rolling_deployment_progress(total_instances, batch_size):
progress = []
updated = 0
while updated < total_instances:
batch = min(batch_size, total_instances - updated)
updated += batch
progress.append((updated, total_instances - updated))
return progress
Notice the last batch is only 1 instance, not 3 -- min(batch_size, total_instances - updated) always caps a batch at whatever's actually left, the same 'don't overshoot the remaining amount' pattern used in Kafka's consume_from_offset when a partition has fewer messages left than the requested batch_size.
Write `rolling_deployment_progress(total_instances, batch_size)`: repeatedly update up to `batch_size` instances at a time until all `total_instances` are updated. Return a list of `(updated_count, remaining_old_count)` tuples, one per batch, tracking cumulative progress.
Model Deployment's `versioning` module covered canary rollouts (a growing PERCENTAGE of traffic). How does a rolling deployment differ?
You can compute rolling deployment progress batch by batch, and distinguish it from a canary rollout's traffic-percentage-based approach.