部署前测试TypeORM迁移脚本的最佳实践方案问询

一、如何在不应用Schema的前提下测试迁移脚本 #

1. 基于生产克隆环境做真实测试 #

• 用AWS RDS快照创建与生产完全一致的测试数据库（包含真实数据结构和脱敏后的业务数据），确保测试环境和生产的数据库版本、配置完全匹配。
• 本地测试的话，可通过pg_dump（PostgreSQL）或mysqldump（MySQL）导出生产数据，导入本地数据库后执行迁移，验证数据兼容性。

2. 使用TypeORM的--dry-run参数预览SQL #

• 执行迁移命令时添加--dry-run参数，TypeORM会输出所有将要执行的SQL语句，但不会实际修改数据库：

  npx typeorm migration:run --dry-run
  

• 直接检查输出的SQL，排查语法错误、数据冲突（比如修改非空字段但现有数据为空）等问题。

3. 本地模拟生产环境执行迁移 #

• 用Docker搭建与生产同版本的数据库容器，配合相同版本的TypeORM、Node.js环境，连接克隆的测试库执行迁移，观察是否有报错，同时验证数据变更是否符合预期。

二、Schema更新与应用部署的最优简便方案 #

1. 禁用自动迁移，改用CI/CD或Beanstalk钩子手动触发 #

• 关闭配置中的migrationsRun: true，避免部署时应用启动依赖迁移执行，减少部署失败风险。
• 利用AWS Elastic Beanstalk的.ebextensions钩子，在应用部署前单独执行迁移（仅在主实例执行，避免多实例重复操作）：
  创建.ebextensions/migration.config文件：

  container_commands:
    01_run_migrations:
      command: "npm run typeorm migration:run"
      leader_only: true
  

• 也可以在CI/CD流程中先执行迁移（可先加--dry-run校验），确认成功后再部署应用，实现迁移与部署的解耦。

2. 规范迁移脚本编写 #

• 单一职责：每个迁移脚本只处理一个Schema变更（比如只加一个字段、只改一个索引），便于问题定位和回滚。
• 处理数据兼容：比如添加非空字段时，分三步执行：先添加允许为空的字段→批量填充默认值→修改字段为非空，避免直接修改导致数据冲突。
• 验证回滚逻辑：确保迁移脚本的down方法能正确回滚变更，测试阶段要验证回滚操作的有效性。

3. 配合蓝绿部署降低变更风险 #

• 对于大型Schema变更（如拆分表、修改核心字段），采用蓝绿部署：
  1. 部署新版本应用到蓝环境，确保新应用兼容旧Schema。
  2. 在蓝环境执行迁移（迁移需保证向前兼容，旧版本应用仍能正常运行）。
  3. 验证蓝环境正常后，切换流量到蓝环境，最后销毁旧的绿环境。
• 这种方式能在迁移出问题时快速切回旧环境，将影响降到最低。

4. 完善监控与日志 #

• 在CI/CD或Beanstalk钩子中记录迁移执行日志，便于故障排查。
• 开启生产数据库的查询日志，记录迁移执行的SQL语句和耗时，出现异常时可快速定位问题。

内容的提问来源于stack exchange，提问作者beckersense