Pre-Deployment Check
Walk through this checklist with the user before any production deploy. If a target is provided, scope the check to that feature or release. Present each category, confirm status, and flag anything unresolved.
Pre-Deploy Checklist
Work through each category. Mark items as pass, fail, or N/A.
Code
| Check |
Details |
| All tests pass |
Run the full test suite. No skipped tests unless documented. |
| No console.logs / debuggers |
Search for console.log, console.debug, debugger statements in changed files. |
| Linting clean |
lint command exits with zero errors and zero warnings. |
| PR approved |
At least one approval from a reviewer who understands the changed area. |
| Changes rebased |
Branch is up to date with the target branch. No merge conflicts. |
Database
| Check |
Details |
| Migrations tested locally |
Run migrations on a fresh local database and verify the schema. |
| Migrations reversible |
Every up has a corresponding down. Test the rollback. |
| No breaking schema changes |
Dropping columns, renaming tables, or changing types requires a multi-step migration plan. |
| Seeds updated |
If migrations change structure, seed files still work. |
Environment
| Check |
Details |
| New env vars in production |
Every new variable from .env.local is set in the production environment. |
| Secrets rotated if needed |
If a secret was exposed or is being replaced, rotate it before deploy. |
| Feature flags configured |
New flags exist in the flag service and are set to the correct default for production. |
Dependencies
| Check |
Details |
| Lock file committed |
pnpm-lock.yaml / package-lock.json / yarn.lock is checked in and up to date. |
| No known vulnerabilities |
Run pnpm audit (or equivalent). No critical or high severity issues. |
| No untested major version bumps |
Major dependency upgrades have been tested in staging or a preview environment. |
Performance
| Check |
Details |
| No bundle size regressions |
Compare bundle output before and after. Flag increases > 5%. |
| Lighthouse check on key pages |
Run Lighthouse on landing page, main app page. No score drops > 5 points. |
| No N+1 queries |
Review new database queries. Use eager loading or batching where needed. |
Monitoring
| Check |
Details |
| Error tracking configured |
New features report errors to Sentry or equivalent. Source maps uploaded. |
| Alerts set |
Critical paths have alerting. New endpoints included in uptime checks. |
| Logging adequate |
Key operations log enough to debug issues without leaking sensitive data. |
Rollback Plan
Define the rollback strategy before deploying. Don't deploy without one.
| Scenario |
Action |
| Bug in application code |
Revert the commit and redeploy the previous version. |
| Feature behaving unexpectedly |
Toggle the feature flag off. No redeploy needed. |
| Database migration failure |
Run the down migration. If irreversible, restore from the pre-deploy backup. |
| Third-party service outage |
Activate fallback or circuit breaker. Communicate status to users. |
Steps for every rollback:
- Identify the issue and confirm it's deploy-related.
- Execute the appropriate action from the table above.
- Verify the rollback resolved the issue (check error rates, run smoke tests).
- Notify the team with a brief incident summary.
Smoke Tests
Run these critical paths immediately after deploy. Fail any one and trigger the rollback plan.
| Path |
What to verify |
| Auth flow |
Sign up, sign in, sign out, password reset all complete without errors. |
| Main CRUD operations |
Create, read, update, delete on the primary resource. Confirm data persists. |
| Payment flow (if applicable) |
Test checkout with a test card. Verify webhook delivery. Confirm no double charges. |
| API health |
Hit /api/health. Expect 200 with all services reporting healthy. |
| Email / notifications |
Trigger a transactional email or notification. Confirm delivery. |
| Key integrations |
Verify third-party API calls succeed (OAuth, webhooks, external data). |
Deploy Strategy
Choose the right strategy based on risk and infrastructure.
| Strategy |
How it works |
When to use |
Risk level |
| Rolling |
Replace instances one at a time. |
Low-risk changes, stateless services. |
Low |
| Blue-green |
Run two identical environments. Switch traffic after verification. |
Database migrations, breaking API changes. |
Medium |
| Canary |
Route a small percentage of traffic to the new version. Monitor, then expand. |
High-risk changes, large user base, uncertain performance impact. |
Lowest |
| Recreate |
Stop all old instances, start new ones. Brief downtime. |
Dev/staging environments, or when downtime is acceptable. |
Highest |
Output Format
Present the checklist as a walkthrough. For each category:
- List the checks with their current status.
- Flag any items that fail or need attention.
- Summarize at the end: ready to deploy, or blocked with specific items to resolve.
1---2name: deploy-check3description: Pre-deployment checklist covering migrations, environment variables, feature flags, rollback plan, and smoke tests. Use when user says "ready to deploy", "deployment checklist", "pre-deploy check", "can I ship this", "deploy review", or needs to verify everything is ready before pushing to production.4---56# Pre-Deployment Check78Walk through this checklist with the user before any production deploy. If a `target` is provided, scope the check to that feature or release. Present each category, confirm status, and flag anything unresolved.910## Pre-Deploy Checklist1112Work through each category. Mark items as pass, fail, or N/A.1314### Code1516| Check | Details |17|-------|---------|18| All tests pass | Run the full test suite. No skipped tests unless documented. |19| No console.logs / debuggers | Search for `console.log`, `console.debug`, `debugger` statements in changed files. |20| Linting clean | `lint` command exits with zero errors and zero warnings. |21| PR approved | At least one approval from a reviewer who understands the changed area. |22| Changes rebased | Branch is up to date with the target branch. No merge conflicts. |2324### Database2526| Check | Details |27|-------|---------|28| Migrations tested locally | Run migrations on a fresh local database and verify the schema. |29| Migrations reversible | Every `up` has a corresponding `down`. Test the rollback. |30| No breaking schema changes | Dropping columns, renaming tables, or changing types requires a multi-step migration plan. |31| Seeds updated | If migrations change structure, seed files still work. |3233### Environment3435| Check | Details |36|-------|---------|37| New env vars in production | Every new variable from `.env.local` is set in the production environment. |38| Secrets rotated if needed | If a secret was exposed or is being replaced, rotate it before deploy. |39| Feature flags configured | New flags exist in the flag service and are set to the correct default for production. |4041### Dependencies4243| Check | Details |44|-------|---------|45| Lock file committed | `pnpm-lock.yaml` / `package-lock.json` / `yarn.lock` is checked in and up to date. |46| No known vulnerabilities | Run `pnpm audit` (or equivalent). No critical or high severity issues. |47| No untested major version bumps | Major dependency upgrades have been tested in staging or a preview environment. |4849### Performance5051| Check | Details |52|-------|---------|53| No bundle size regressions | Compare bundle output before and after. Flag increases > 5%. |54| Lighthouse check on key pages | Run Lighthouse on landing page, main app page. No score drops > 5 points. |55| No N+1 queries | Review new database queries. Use eager loading or batching where needed. |5657### Monitoring5859| Check | Details |60|-------|---------|61| Error tracking configured | New features report errors to Sentry or equivalent. Source maps uploaded. |62| Alerts set | Critical paths have alerting. New endpoints included in uptime checks. |63| Logging adequate | Key operations log enough to debug issues without leaking sensitive data. |6465## Rollback Plan6667Define the rollback strategy before deploying. Don't deploy without one.6869| Scenario | Action |70|----------|--------|71| Bug in application code | Revert the commit and redeploy the previous version. |72| Feature behaving unexpectedly | Toggle the feature flag off. No redeploy needed. |73| Database migration failure | Run the `down` migration. If irreversible, restore from the pre-deploy backup. |74| Third-party service outage | Activate fallback or circuit breaker. Communicate status to users. |7576Steps for every rollback:771. Identify the issue and confirm it's deploy-related.782. Execute the appropriate action from the table above.793. Verify the rollback resolved the issue (check error rates, run smoke tests).804. Notify the team with a brief incident summary.8182## Smoke Tests8384Run these critical paths immediately after deploy. Fail any one and trigger the rollback plan.8586| Path | What to verify |87|------|---------------|88| Auth flow | Sign up, sign in, sign out, password reset all complete without errors. |89| Main CRUD operations | Create, read, update, delete on the primary resource. Confirm data persists. |90| Payment flow (if applicable) | Test checkout with a test card. Verify webhook delivery. Confirm no double charges. |91| API health | Hit `/api/health`. Expect 200 with all services reporting healthy. |92| Email / notifications | Trigger a transactional email or notification. Confirm delivery. |93| Key integrations | Verify third-party API calls succeed (OAuth, webhooks, external data). |9495## Deploy Strategy9697Choose the right strategy based on risk and infrastructure.9899| Strategy | How it works | When to use | Risk level |100|----------|-------------|-------------|------------|101| **Rolling** | Replace instances one at a time. | Low-risk changes, stateless services. | Low |102| **Blue-green** | Run two identical environments. Switch traffic after verification. | Database migrations, breaking API changes. | Medium |103| **Canary** | Route a small percentage of traffic to the new version. Monitor, then expand. | High-risk changes, large user base, uncertain performance impact. | Lowest |104| **Recreate** | Stop all old instances, start new ones. Brief downtime. | Dev/staging environments, or when downtime is acceptable. | Highest |105106## Output Format107108Present the checklist as a walkthrough. For each category:1091. List the checks with their current status.1102. Flag any items that fail or need attention.1113. Summarize at the end: ready to deploy, or blocked with specific items to resolve.
kazdenc