Skip to content

How would you roll back the app while keeping current infrastructure?

1 min read · main part only; folded sections are optional

After this you can answer: How would you roll back the app while keeping current infrastructure?

There are separate version axes: application artifacts, infrastructure code, database schema and queued event formats. An old image is usable only if it still understands the current state it will encounter.

A manual CD run on main with an existing image tag skips publication and uses main’s infrastructure checkout. Phase B changes the shared SSM image tag; the infrastructure program reads that value for the services. The committed stack file describes environment shape rather than storing release image overrides.

An image rollback may restore application behavior while leaving an additive schema change in place. It will not unsend emails, restore deleted data or undo accepted bookings. I would verify the affected business behavior and watch queues after the rollback, not rely only on a green workflow. If the old image cannot handle the new schema or queued events, a forward fix may be the safer recovery.

Should you approve an older waiting workflow?
No. That can use an older infrastructure checkout. Start the documented manual image deployment from current main instead.
Does changing the SSM tag prove recovery?
No. It records desired version. Confirm ECS revisions, Lambda images, triggers and the affected request path.
How do you keep rollback images?
The registry retention design preserves deployed tags. Check the exact desired artifact still exists before beginning recovery.

Read the path chapter, select the relevant map piece →, then inspect infra/src/release.ts → readDeployedImageTag. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/