mysql - rails : preventing bad/conflicting database migrations

Question

只是想知道这些是否可以通过 rubocop 或直接通过 ci 以某种方式预防。

我们最初在主分支上进行了一些迁移:

# migration 1
create_table :some_table do |t|
  t.string :some_col
end

# migration 2
def change
  rename_column :some_table, :some_col, :some_other_col
end

但是，我们还有一个单独/较旧的分支，其中 some_table 中的列被直接重命名:

create_table :some_table do |t|
  t.string :some_col
end

它被合并到/通过了 ci 并在生产中运行，没有任何问题，但是在几周后部署到新的测试环境时抛出 No such columns: some_table 错误时被捕获。

Answer 1

引用自:rake db:schema:load vs rake db:migrate这解释了这个确切的问题:

when you are adding a new migration to an existing app then you need to run rake db:migrate, but when you join to existing application (especially some old application), or when you drop your applications database and you need to create it again, always run rake db:schema:load to load schema.

本质上，当您启动新实例时，请始终使用 db:schema:load 加载初始数据库，从那时起您就可以照常迁移。