本地到 CI 的 Sequelize Migration 工作流

Sequelize 的 migration 在演示里总是很简单，真正到了团队协作阶段，问题就变成了另一种：本地能跑，测试环境半残，CI 里还会因为顺序不一致把表结构跑歪。

我现在更推荐把 migration 当成发布工件，而不是临时脚本。也就是说，谁创建 migration、谁评审、谁执行，都要落在一个清晰流程里。最重要的不是生成文件，而是保证每个环境看到的是同一组变更。

一个比较稳的顺序通常是：

1. 本地先改模型，再补 migration。
2. 用一份干净数据库完整执行一遍，确认不是依赖当前脏数据。
3. 把 migration 放进 CI，确保每次构建都能从零还原结构。
4. 线上只执行已经合并的 migration，不现场手改表。

这样做的价值，在于把“改数据库”从个人操作变成团队可追踪的流程。Sequelize 的 migration 并不神奇，但只要本地到 CI 的节奏一致，后面排查结构差异就会轻松很多。