Rolling Deployment

Imagine repainting a long fence. You don't strip every plank bare at once — the whole yard would sit unprotected. Instead, you repaint a few planks, check they look right, then move to the next few. A rolling deployment updates a group of servers the same way. Instead of replacing every server with the new version at once, it updates a few at a time, called a 'batch.' It checks each one is healthy, then moves on to the next batch. At every moment, most of the fence — most of your servers — is still standing and serving traffic.

1. 1Split all the servers into small batches, say 2 at a time, instead of touching everyone at once.
2. 2Update one batch: take those servers off the old version (v1) and put them on the new version (v2).
3. 3Run a health check on each just-updated server. If it's healthy, move on to the next batch.
4. 4If a server fails its health check, roll it back and retry before you continue. Never leave a broken server serving real traffic.

Use this when you deploy a new version of an app that runs on many servers, and you can't afford to take everything down at once. Rolling deployment keeps the app up the whole time. Some servers are always still on the old, working version while others get updated.

• ⚠Using a batch size so large it's basically 'update everything at once.' That brings back the all-or-nothing risk a rolling deployment is meant to avoid.
• ⚠Skipping the health check after each batch. A broken update can then quietly spread to every server before anyone notices.
• ⚠Having no rollback plan for a server that fails its check. 'Push forward and hope' isn't a strategy.