serial & Rolling Batch Execution

Updating every server in one sweep is fast, but a bad change can take down your whole fleet at the same instant. Rolling updates avoid that.

The serial keyword tells a play to work through hosts in batches instead of all together. You update a slice, then move to the next.

Give serial a number and each batch holds that many hosts. With serial 2, Ansible finishes the whole play on two hosts before touching the rest.

A percentage scales with fleet size. serial: 25% updates a quarter of hosts per wave, whether you have 8 servers or 800.

Pass a list to grow batches as confidence builds: start with one host, then more. This is the classic canary then full rollout pattern.

Crucially, serial runs the entire play on a batch before the next. The first slice is fully done while later hosts have not started.

Pair serial with max_fail_percentage to abort the rollout if too many hosts in a batch fail, stopping a bad change before it spreads.

A safe wave first removes each batch from the load balancer, applies changes, then adds the hosts back so users never hit a server mid-update.

Because other batches keep serving traffic, rolling updates give you zero downtime: the app stays available throughout the deploy.

Within a batch, forks still control parallelism. serial caps how many hosts a wave touches; forks caps how many run at once inside it.

Starting with serial: 1 makes the first host a canary. If it breaks, the run stops there and the rest of your fleet stays healthy.

You want to update 100 web servers a few at a time without an outage.

Use serial to roll changes out in batches, ramp with a list, and add max_fail_percentage to bail early. That is zero-downtime deploys. 🌊