本地到 CI 的 Sequelize Migration 工作流

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

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

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

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

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

为什么这类问题总会在线上阶段突然变贵

围绕「本地到 CI 的 Sequelize Migration 工作流」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。