RollingDeployment
Upgrade targets incrementally, a batch at a time, replacing the old version as you go — no second full environment needed (unlike blue-green), but rollback means rolling forward again with the old version.
Why we need this / what value this brings
Avoids the cost of a full duplicate environment (unlike blue-green) while still limiting blast radius somewhat by going batch by batch — the common default for infrastructure that can't easily be doubled.
When to use this
Resource-constrained environments (can't run two full fleets at once) where some blast-radius control is still wanted.
How to use or implement this
Batch the rollout, verify each batch before proceeding to the next, and — critically, given the scenario — have an explicit, automated 'stop and don't proceed' action wired to a verification failure, not just a log entry a human might not see in time.
Research questions
- This is closest to the described scenario ('upgrade software again to older version') — rolling deployments don't get a free instant-rollback the way blue-green does, since there's no idle old environment sitting ready.
Empty folder — drop notes, links, and findings here as you research.