DeploymentStrategies
How a change actually gets rolled out to a fleet of targets (servers, containers, or network devices), and — critically — what happens when the post-deploy check fails. This applies just as much to a network device golden-image firmware upgrade as it does to a web app deploy.
Why we need this / what value this brings
The rollout mechanism determines your actual blast radius and recovery time when something goes wrong — 'we'll just fix it after' isn't a strategy, it's the absence of one, which is exactly what turned a failed PIV into a manual scramble in the scenario.
When to use this
Decide the rollout strategy and the rollback plan together, before the first deploy — not improvised the first time a verification step fails.
How to use or implement this
Match the strategy to blast-radius tolerance and rollback speed needed: canary/rolling for gradual, lower-risk rollout; blue-green when instant rollback matters more than the cost of a duplicate environment.
Subtopics
- BlueGreen
- Canary
- GoldenImage ImmutableInfrastructure
- PostImplementationVerification PIV
- Recreate BigBang
- RollbackStrategies
- RollingDeployment
Research questions
- Scenario to test this folder against: an automation tool pushes a golden image to a device, a separate PIV (post-implementation verification) automation tool checks it, PIV fails, and there's no automated rollback — so the fix is manually re-pushing the older image. Which subfolder covers each part of that?
Empty folder — drop notes, links, and findings here as you research.