Rolling Deployment
A rolling deployment replaces old application instances with new ones in batches. Each step changes only part of the running group, so versions may overlap.
old batch -> start and verify new batch -> drain old batch -> repeat- 1v1
- 2v1
- 3v2 ✓
- 4v2 ✓
2 / 2 ready→old batch -> start and verify new batch -> drain old batch -> repeatOPSAnother example
A service has four instances. One extra may start, but none may be unavailable. Each ready batch allows the next replacement.
Main parts
- 01Old instance group
- 02New instance group
- 03Batch size
- 04Unavailable and extra limits
- 05Readiness and drain
- 06Pause and rollback rule
Use it when
Use it when both versions can run together and healthy capacity can remain. Define batch, readiness, pause, failure, and rollback rules.
Do not use it when
Do not promise zero downtime. Weak readiness checks, low capacity, long connections, or incompatible data changes can still interrupt service.
Name used in code
old batch -> start and verify new batch -> drain old batch -> repeat Before you ship
Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.
Outcome: Use Rolling Deployment to release or recover the change safely, with a clear record. User context: A service has four instances. One extra may start, but none may be unavailable. Each ready batch allows the next replacement. Delivery concept or operation: Rolling Deployment. Why it fits: Use it when both versions can run together and healthy capacity can remain. Define batch, readiness, pause, failure, and rollback rules. Do not use it when: Do not promise zero downtime. Weak readiness checks, low capacity, long connections, or incompatible data changes can still interrupt service. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.
Check this request
Review the current use of Rolling Deployment. Definition: A rolling deployment replaces old application instances with new ones in batches. Each step changes only part of the running group, so versions may overlap. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.