Rails: лучший способ внести изменения в производственную базу данных

Есть ли причина, по которой вы не используете те же миграции, которые использовали в своей среде разработки?

Добавление столбца с add_column в миграцию должно быть неразрушающим: он будет генерировать инструкцию «ALTER TABLE». Если вы знаете, что вы собираетесь поместить в столбцы после создания, вы можете заполнить значения в рамках миграции (вы можете выбрать менее трудоемкую альтернативу, если количество строк велико).

Удаление или изменение определения столбца, я думаю, зависит от платформы: некоторые разрешают удаление столбца на месте, другие выполняют последовательность команд переименовать-создать-выбрать-удалить.

Чтобы быть более конкретным, нам нужна дополнительная информация: какой тип миграции вы рассматриваете, на какой платформе вы работаете, нужно ли вам устанавливать значения в рамках миграции? Подобные вещи могут очень помочь - просто отредактируйте вопрос, и он вернется вверх по списку.

Я всегда следую такой процедуре:

• Дамп базы данных prod с помощью команды mysqldump
• Заполните базу данных dev / test дампом с помощью команды mysql
• Запустить миграции в dev / test
• Проверить, что миграция прошла
• Дамп базы данных prod с помощью команды mysqldump (поскольку она могла быть изменена) с сохранением резервной копии на сервере
• Запускать миграции на продукте (используя capristano)
• Тестовая миграция сработала на прод
• Пейте пиво (просматривая журналы ошибок)

Похоже, вы находитесь в состоянии, когда рабочая схема базы данных не совсем соответствует тому, что вы используете в dev (хотя это не совсем понятно). Я бы нарисовал линию на песке, и получил бы этот prod db в лучшем состоянии. По сути, вы хотите, чтобы в prod db была таблица schema_info, в которой перечислены все миграции, которые вы никогда не хотите запускать в производственной среде. Затем вы можете добавить миграции к своему сердцу, и они будут работать против производственной базы данных.

После того, как вы это сделаете, вы можете написать миграции, которые добавляют изменения схемы или данные, но вам нужно быть очень осторожным с тем, что если вы добавляете данные с помощью миграции, вы должны определить модель внутри самой миграции, например :

class AddSomeColumnsToUserTable < ActiveRecord::Migration
  class User < ActiveRecord::Base; end
  def self.up
    add_column :users, :super_cool, :boolean, :default => :false
    u = User.find_by_login('cameron')
    u.super_cool = true
    u.save
  end

  def self.down
    remove_column :users, :super_cool
  end
end

Причина этого в том, что в будущем вы можете полностью удалить модель во время какого-либо рефакторинга. Если вы не определите класс пользователя в строке «User.find_by_login ...», миграция вызовет исключение, что является большой проблемой.