GoldenImage ImmutableInfrastructure
A pre-built, validated, versioned image (VM image, container image, or device firmware image) that gets deployed as a single immutable unit, rather than configuring a live target in place — the specific pattern in the scenario's upgrade tool.
Why we need this / what value this brings
Deploying a pre-validated, versioned image instead of configuring live is what makes 'redeploy the previous version' even possible as a rollback option — you can't roll back to a config state that was never captured as an artifact.
When to use this
Any repeatable deployment, especially device/firmware upgrades or VM/container fleets, where consistency and rollback-ability matter.
How to use or implement this
Version and retain every golden image (not just the latest), tag each with what it contains, and make 'redeploy image X' a single, tested, repeatable operation — not a manual rebuild process improvised under pressure.
Research questions
- Was the previous golden image kept versioned and readily available, or did 'upgrade to the older version' mean re-building/re-locating it under time pressure? That answer is what determines whether rollback is fast or slow.
- Immutable image deploys make rollback conceptually simple (just deploy the previous image again) — see RollbackStrategies for why that's still not the same as automated rollback.
Empty folder — drop notes, links, and findings here as you research.