How do you know a successful deployment actually runs the new code?

Say it in 30 seconds

Say it like this (20-30 seconds)

I separate publishing an artifact, applying infrastructure and proving the running version. MiniTickets publishes immutable commit-tagged images, applies infrastructure and migrations first, then changes the shared release tag and rolls services. It checks running task-definition revisions, both Lambda images and queue triggers, followed by smoke tests. A stable ECS service is insufficient because the deployment circuit breaker can restore the previous revision and leave that old version stable.

The deeper answer

The CI-triggered publish job checks out the exact commit CI tested, rather than whichever commit main contains later. It publishes API, web and worker images. Deployment checks that the chosen tag exists before changing the environment.

Phase A normally keeps running services on the current SSM image tag while creating infrastructure and selecting the new migration image. After migration succeeds, phase B updates the release tag and rolls application resources. First deployment and worker compatibility fallbacks are exceptions: there may be no usable previous image to preserve.

Verification must distinguish desired state from observed state. Compare running ECS task definitions with those registered for this deployment, then verify Lambda images and enabled mappings. Smoke checks of / and /trpc/events.list cover a narrow public path. They do not prove login, booking or asynchronous completion. A production release would choose additional checks according to the change and its risk.

Counter-questions

Why build once?

Reusing the published image preserves the artifact under review. Rebuilding during deploy could produce different dependency or base-image content.

What if migration fails?

The job stops before phase B. Infrastructure changes from phase A can remain; inspect them rather than assuming the whole deploy rolled back.

Would you add every end-to-end test as a smoke check?

No. Keep deployment checks bounded and reliable, then use broader tests and monitoring for wider coverage.

Where in MiniTickets

Read the path chapter, select the relevant map piece →, then inspect .github/workflows/cd.yml → deploy. Work through the related case for a diagnostic example.