Deploy a web app with a safe path back
Understand local, preview, and live environments before sharing an app with real users.
By the end, you can describe what is deployed, check the right environment settings, and plan how to notice and recover from a failed release.
Step 1: Know which shop is opening
Local runs on your computer. Preview is a place to inspect a proposed version. Production is the service real users rely on. Treat them as separate shops with different addresses, stockrooms, and settings. A working preview can still target the wrong database.
Step 2: Separate application and data changes
A is a recorded change to the structure of saved data. Adding a field, renaming it, and deleting have different consequences. Preview rehearsal is evidence, not a complete release plan. Old open browsers may still expect older fields during a deployment.
Step 3: Ask for rollout and recovery
Ask which browser code, server behavior, database changes, and external services go live, in what order. Where needed, add compatible support before moving readers and removing old fields. Keep private configuration on the server. State code and data backup/repair separately.
Step 4: Check before promotion
Use preview data to test sign-in, a main flow, a failure, mobile layout, and permissions. Read relevant redacted deployment logs. If sign-in email arrives but opening it gives a redirect error, check the allowed preview return address. If no email arrives, inspect provider/delivery errors instead. Do not publish until the evidence and recovery plan are reviewed.
Identify the preview and production service connections without printing secrets. Show rehearsal results, compatibility with old clients, the production rollout order, and separate code/data recovery steps. Inspect the preview’s main and failure paths using test accounts. Wait for review before publishing. Illustrative before / after (behavior, not ready-to-run code): - Build succeeded → production + Preview evidence → environment check → compatible rollout → recovery plan
Redeploying old code does not restore deleted or unsend an email. A plan must identify what it can actually recover.
Picture it, then try it
Evidence and recovery have separate parts
A practice shop and a live shop have different stockrooms. Replacing the storefront does not restore stock already thrown away.
Local → test data Preview → reviewed test environment Production → real users + real data Preview: behavior Diff: code changes Code recovery Data backup / repair Webhook → verify sender → recognize event ID → one effect
AI changed a button and dropped a database field. Will redeploying the old app restore ? What must the release plan show?
Compare your reasoning with the worked answer
Old code does not restore deleted . Ask for the target database, rehearsal, compatibility with old clients, production order, and actual data recovery evidence. Keep checks observable: phone interaction, rejected save, and ordinary-user access. A is a provider's event sent to your server; verify authenticity and recognize repeats before creating another effect.
Sources and further reading
The release builds. Its preview opens, but you have not checked which database it connects to. What should happen before public release?
Choose one answer.