{"slug":"operations/deployment-and-rollback","title":"Deployment And Rollback Runbook","section":"operations","sectionLabel":"Operations","status":"unclassified","type":"document","path":"operations/deployment-and-rollback.md","bytes":2418,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nUse this runbook when a release needs to be deployed safely, rolled back quickly, or stabilized after a bad change.\n\n## Before Deploying\n\n1. Confirm scope: frontend, one Worker, multiple Workers, migration, or config-only.\n2. Run the relevant validation:\n   - `pnpm build`\n   - targeted tests for changed services\n   - migration review for backward compatibility\n3. Confirm rollback owner and communication path.\n4. Check whether the change affects:\n   - auth\n   - tenant resolution\n   - webhook verification\n   - queue consumers\n   - Spine writes\n\n## Preferred Deploy Order\n\nWhen multiple Workers are changing, deploy downstream services first and Gateway last.\n\n- data and processing layers\n- supporting Workers\n- public ingress layer\n\nUse the documented Cloudflare deployment flow and repo scripts instead of ad hoc local commands where possible.\n\n## Post-Deploy Verification\n\n- health endpoints return success\n- one authenticated tenant-scoped request works end to end\n- webhook or sync path still verifies and routes correctly\n- no unexpected spike in retries, DLQ depth, or 5xx rate\n\n## When To Roll Back\n\nRoll back when:\n\n- a deploy introduces customer-facing breakage\n- auth or tenant resolution fails\n- webhook verification breaks\n- new writes are unsafe or corrupting\n- the fix-forward path is slower or riskier than reverting\n\n## Rollback Procedure\n\n1. Stop additional risky deploys.\n2. Identify whether the issue is:\n   - code only\n   - config or secret drift\n   - schema or migration related\n3. Revert the failing Worker or Pages deployment using the last known good version.\n4. Re-run smoke checks on the affected path.\n5. Keep the incident open until queue backlog, retries, and error rate normalize.\n\n## Database Rollback Rule\n\nDo not perform destructive database rollback directly in production unless you have:\n\n- a confirmed blast radius\n- a backup or PITR plan\n- validation criteria\n- a communication plan\n\nFor schema or data damage, use [data-recovery.md](data-recovery.md) instead of improvising.\n\n## Quick Rollback Checklist\n\n- previous working version identified\n- rollback owner assigned\n- affected tenants identified\n- smoke test path ready\n- recovery window monitored after rollback\n\n## Related Docs\n\n- [../DEPLOYMENT_BEST_PRACTICES.md](../DEPLOYMENT_BEST_PRACTICES.md)\n- [incident-response.md](incident-response.md)\n- [data-recovery.md](data-recovery.md)\n"}