44 lines
1.4 KiB
Markdown
44 lines
1.4 KiB
Markdown
# Rollback & Recovery
|
|
|
|
## Levels of Rollback
|
|
|
|
### 1. Code Rollback (Most Common)
|
|
- Dokploy keeps previous builds
|
|
- Redeploy previous compose version from Dokploy UI
|
|
- Or: `git revert` the breaking commit, push, redeploy
|
|
|
|
### 2. Database Rollback
|
|
- Drizzle doesn't auto-generate down migrations
|
|
- For schema changes, write explicit rollback SQL before deploying
|
|
- Keep a `migrations/rollback/` directory with undo scripts
|
|
- For data issues: restore from Dokploy Postgres backup
|
|
|
|
### 3. Full Rollback
|
|
- Dokploy allows complete service redeployment from any previous state
|
|
- Database: restore from backup
|
|
- Last resort: rebuild from Gitea source at known-good commit
|
|
|
|
## Pre-Deploy Checklist
|
|
|
|
Before any production deployment:
|
|
- [ ] Feature works in test environment
|
|
- [ ] User has approved in test
|
|
- [ ] DB migration tested (if schema changed)
|
|
- [ ] Rollback SQL written (if schema changed)
|
|
- [ ] Health check passes after deploy
|
|
|
|
## Staging Environment
|
|
|
|
- Staging should mirror production schema
|
|
- Periodically sync staging DB schema with prod
|
|
- Never sync prod DATA to staging (privacy)
|
|
- Test migrations on staging before prod
|
|
|
|
## If Something Breaks in Prod
|
|
|
|
1. **Assess severity** — is the app down or is it a bug?
|
|
2. **If app is down** — redeploy previous Dokploy build immediately
|
|
3. **If it's a bug** — fix in dev, test, deploy fix
|
|
4. **If DB is corrupted** — restore from backup, investigate cause
|
|
5. **Notify user** with what happened and what was done
|