Блог

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

• разные версии кода в одном приложении rails.
• различные версии приложения rails во время развертывания для пользователей.
• разные структуры базы данных между версиями
• перемещение данных по новым базам данных и серверам.

вот несколько идей для обсуждения вышеизложенного

• операторы if с константой, номера версий в именах M, V, C.
• баланс нагрузки на разные серверы приложений (как сделать sticky?), RVM
• сделайте старые и новые поля в таблицах временными или перенесите записи в новые таблицы или
  базы данных.
• нет простого способа перемещать данные между серверами.

Похоже, вам нужна хорошая стратегия ветвления и слияния. Если вы используете что-то вроде Git или SVN, то все, что находится в master или trunk, соответственно, должно быть готового к производству качества. Если вы сталкиваетесь с ситуациями, когда AbcController все хорошо и готово к работе, но XyzController не работает, то XyzController , вероятно, требуется дополнительное тестирование, и оно еще не должно быть в master.

Миграции в rails также соответствуют этой политике, которая приводит к вашей структуре данных. Если вы считаете, что готовы к работе, то в вашей базе данных не должно быть существенных изменений. Возможно, вам нужно добавить столбец или функцию, но вы уже давно прошли массовый рефакторинг базы данных.

Наконец, загрузка / обновление данных — это проблема в любой ситуации миграции. По моему опыту, это включает в себя написание SQL-скриптов для выполнения перемещений или обновления базы данных для какой-либо новой функции. Эти SQL-скрипты также должны находиться под вашим управлением исходным кодом. Rails может упростить это, написав ваши сценарии миграции в самом файле миграции. В зависимости от вашей конкретной ситуации это может сработать.