Workflows
数据库迁移安全工作流
将数据库 schema 变更拆分为可回退、可观测、可分阶段执行的迁移流程，降低发布期结构变更风险。
- 要把命令组合成稳定流程的团队成员
- 需要处理协作顺序和分支边界的人
- 知道 fetch / pull / push / branch 的基本作用
- 能理解一条分支为什么会分叉
- 照抄流程却没确认当前分支关系
- 在共享分支上用错整合方式
数据库迁移失败的代价通常高于应用层发布失败。安全迁移的关键，是把一次不可逆大改拆成多个可控小步骤。
迁移脚本兼容代码回退方案
迁移风险降低回滚更可行线上中断更少
先扩展后收缩，是多数生产迁移的保守策略。
推荐流程
1. Expand：先加新字段/新表，不删旧结构
先让旧逻辑继续工作，避免立即破坏兼容性。
2. Backfill：补历史数据
批量补数要控制速率，避免影响线上性能。
3. Switch：逐步切读写路径
先读新写双写或影子验证，再切换主路径。
4. Contract：确认稳定后清理旧结构
旧字段删除应延后到多个发布周期之后。
发布前检查清单
- 是否有回退脚本或等价回退策略
- 是否有慢查询/锁等待监控
- 是否评估了迁移窗口与流量高峰冲突
- 是否完成了预发数据量级演练
在未确认全链路已切换完成前，直接删除旧结构会让回滚成本暴增。优先延迟清理，先确保稳定。
常见误区
误区 1：开发环境通过就直接上生产
真实数据规模会放大锁竞争和回填耗时问题。
误区 2：迁移脚本和应用发布强绑定
应允许迁移先行、应用后切换，避免耦合失败。
误区 3：回退方案只写“必要时回滚”
没有具体动作步骤的回退方案等于没有方案。
- 写出 expand/backfill/switch/contract 四阶段动作。
- 定义每阶段可观测指标。
- 写明每阶段失败后的回退动作。
- 在预发用接近生产体量数据演练一次。
接下来建议继续看什么
Code freeze and release candidate workflowRelease branch workflowHotfix rollback after release