Каково ваше идеальное решение для переноса действительно большой кодовой базы php в rails? - PullRequest
Новая
       2

Каково ваше идеальное решение для переноса действительно большой кодовой базы php в rails?

2 голосов
/ 28 февраля 2011

я просто запрашиваю мнения / советы. Как у нас есть действительно большая база PHP кода , по большому счету это то, что я имел в виду:

более 500 столов более 4000 файлов - действия, дисплеи и шаблоны. более 1 000 000 строк кода - это программное обеспечение работает уже более 8 лет.

Так много устаревшего, дублированного кода повсюду и так много хаков.

Я хочу, чтобы программное обеспечение все еще работало, пока его части переносятся на рельсы.

Так что он будет работать в гибридном режиме, то есть как на PHP, так и на rails одновременно. Части программного обеспечения, которые уже были перенесены, начнут использовать версию Rails.

Полагаю, моя идея такова:

  1. мигрировать в Git
  2. Полагаю, все более 500 таблиц остались.
  3. Найдите способ взаимодействия PHP и rails?
  4. Жевать по одному дисплею и экрану управления за раз?
  5. Работа на переднем конце?

Ответы [ 2 ]

2 голосов
/ 28 февраля 2011

Хотя я далек от убеждения, что переход с PHP на Ruby сделает вашу жизнь проще, я думаю, что есть очень веские основания для отображения зависимостей в текущей кодовой базе.

  • Какие сценарии PHP являются точками входа в выполнение (т. Е. Отображаются непосредственно на URL-адреса)
  • какие файлы PHP включены в другие сценарии (и какие они есть)
  • какие шаблоны используются каким URL-адресом
  • какие сценарии обращаются к каким таблицам

Это, по крайней мере, позволит вам разделить упражнение на отдельные части.Обратите внимание, что в некоторых случаях может быть хорошей идеей переписать PHP / DB как временную меру, а не переходить непосредственно к Ruby, например

  1. Если есть возможность объединения нескольких таблиц базы данных- затем сделайте это - и создайте представления в результирующей таблице, названной в соответствии с замененной таблицей.

  2. Если необходимо, попробуйте заново реализовать каждый PHP-скрипт точки входа как 'index.php' в своем собственном каталоге - и всегда ссылаться на скрипт по каталогу.Таким образом, вы можете прозрачно начать замену компонентов, написанных на другом языке.

2 голосов
/ 28 февраля 2011

Я ожидаю, что такая штука будет безоблачной. В любом случае позвольте мне дать несколько советов.

  1. Сборка обоих базовых "запускаемых" приложений.
  2. Убедитесь, что оба приложения могут обращаться к одной и той же базе данных, к одним и тем же источникам сеанса, к одному и тому же кешу и так далее. Здесь вы должны убедиться, что ваши источники данных совместимы с обоими приложениями. Например: вы можете перенести ваши пользовательские сессии в базу данных.
  3. Создайте дополнительный компонент маршрутизации (в mod_rewrite, PHP или любом другом), чтобы начать маршрутизацию нескольких страниц в ваше приложение Ruby вместо PHP. Проверьте это тщательно. Постройте маршрутизатор таким образом, чтобы он мог функционировать как в режиме разработки, так и в производственном режиме.
  4. Медленно начните добавлять маршруты к вашему маршрутизатору для добавления компонентов в вашем приложении Ruby.
  5. Когда вы полностью мигрируете, измените маршрут по умолчанию на ваше приложение Ruby. Теперь вы можете начать использовать специфичные для Ruby источники данных.
...