Rails API生产环境Bug修复：如何在合并开发分支前部署迁移？

针对你遇到的问题，核心是利用Rails迁移按文件时间戳追踪执行状态的机制，同时保证迁移的兼容性，具体步骤如下：

• 在生产分支（如main/master）单独创建修复迁移
  直接在生产分支执行迁移生成命令，比如：

  rails generate migration FixProductionCriticalBug
  

  编写修复逻辑后，部署到生产并执行rails db:migrate，此时生产环境的schema_migrations表会记录这个最新时间戳的迁移。

• 将修复迁移同步到开发分支
  把生产分支的修复迁移文件合并到开发分支，绝对不要修改开发分支中已有迁移的时间戳，也不要在开发分支重新创建同名/同功能的迁移。此时开发环境执行rails db:migrate时，会先按时间戳顺序执行所有未完成的旧迁移，再执行新增的修复迁移，不会出现执行顺序问题。

• 确保修复迁移与开发分支旧迁移的兼容性
  修复迁移要满足：

  • 不依赖开发分支中未上线的数据库结构（比如不要引用开发分支新增的表/字段）
  • 做可逆操作（比如新增字段设为null: true，避免后续旧迁移执行时出现数据约束问题）
  • 不修改开发分支旧迁移会操作的核心数据结构（比如如果开发分支要重命名某字段，修复迁移不要对该字段做修改）

• 合并开发分支到生产的注意事项

  1. 先在测试环境完整执行所有迁移（开发分支旧迁移 + 修复迁移），验证没有冲突或数据异常
  2. 生产部署前备份数据库
  3. 合并后执行rails db:migrate，Rails会自动检测所有未在schema_migrations中记录的迁移（包括开发分支的旧迁移），按时间戳顺序执行，不会因为已有较新的修复迁移而跳过旧迁移

关键提醒 #

永远不要修改已提交到版本库的迁移文件，哪怕是时间戳或内容，否则会导致不同环境的迁移执行状态混乱，引发难以排查的问题。

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