Deploy and recover changes
Prepare a release, check it in use, and know how to recover when something fails.
Why this matters
Say you ship a fix on Friday afternoon. Which version is now live, what settings does it use, and how do you undo it if it breaks? Deployment — putting a specific version where people use it — should make each of those answers clear.
What to understand
You likely have local development on your machine, isolated previews for review, and production where real people work. Add staging — a shared pre-production copy — only when it answers a real integration or release question. It is not required for every site. A preview is isolated only if its data and side effects are too.
Watch for
- Preview testing against production data or live side effects — email, payments, uploads, jobs.
- A copied CI template whose test command doesn't exist in this repo.
- Public build-time values assumed changeable without a rebuild.
- Undoing a release assumed to undo a database change or a sent email.
- A hosting dashboard "build passed" claimed as proof the user outcome works.
Strong default
Know whether your app is static output, a server runtime, or a mix. Check deep links, assets, redirects, dynamic routes, metadata, search, and environment variables against your host. Install from the lockfile, run the project's real checks, build, and deploy the candidate. Ask your agent: "what are the actual install, check, and build commands and runtime versions here?"
When this doesn't apply
Staging is not required for every site, and redeploying a prior file set is a fine recovery plan for a static guide — but not for a transactional product where people create, pay, or save. Match the runbook to your system: file-set restore versus reconciling writes and data-shape compatibility.
In practice
Before you test a flow, check database credentials, email delivery, payments, uploads, and background jobs. A prerendered page inside a Next.js deployment does not mean the project is a standalone static export. Public build-time values may need a rebuild to change; server runtime settings have a different lifetime.
If this project deploys on Vercel, the environments map cleanly: production serves the live branch, every pull request gets an isolated preview URL with its own variables, and functions carry the runtime settings. Ask your agent: "which variables differ between preview and production, and what happens to in-flight writes if we roll back?"
Include data and background work. Plan schema changes — changes to how data is shaped — so old and new code can coexist when a rolling release or undo requires it. For a consequential change, name the compatibility boundary and recovery steps. Backups help only if the team knows what they cover and can restore them in time.
Record the last known good version, how to restore or redeploy it, who can act, and when to act. Name data changes or irreversible side effects that limit undoing a release.
Verify
Confirm the live version and environment. Do an authorized, safe smoke check of the key task and look at monitoring. Check that the intended audience can reach it and that errors go to the configured channel.
Related skills
Ask your agent to run $readiness before real use. Continue with observability for detecting failures, and client delivery for the operational package someone inherits.
Last updated on