Запуск нескольких сайтов из одной и той же рельсовой кодовой базы?

Ответ 1

В настоящее время мы работаем с настройкой, очень похожей на то, что вы описываете.

Мы начали разрабатывать несколько большое приложение Rails (продажа, управление запасами, каталог продуктов и т.д.) для клиента. После его завершения появилось несколько новых запросов на почти идентичную функциональность.

Исходное приложение, однако, должно было сохраниться, добавив новые функции, исправляя ошибки и многое другое.

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

Мы сделали несколько шагов:

• Сначала мы начали очищать код, вытягивая ссылки на жесткие ссылки на таблицы, уменьшая и оптимизируя запросы, просматривая отсутствующие индексы и способы улучшения использования ActiveRecord.
• После некоторого удовлетворения мы начали разрабатывать недостающие тесты. Я не могу сказать, что это полезно, потому что мы будем поддерживать одну и ту же базу кода для нескольких приложений и нуждаемся в том, чтобы основные функции были защищены так же, как и от новых изменений.
• Это было также волшебное слово: базовая функциональность. Мы начали выбирать базовые функции, которые можно было бы повторно использовать, и выдать весь общий код. Это дало нам сочетание контроллеров, моделей и просмотров, которые мы начали менять на модули, плагины и драгоценные камни. Что происходит? В значительной степени зависит от вашего кода. Как правило, функциональность, которая не имеет отношения к языку домена, относится к плагинам (или драгоценным камням, если это не слишком сильно зависит от Rails)
  4. Этот подход привел нас к нескольким плагинам, драгоценным камням, которые мы затем собрали вместе, собрав исходный проект, а затем он получил собственный репозиторий GIT. Таким образом, у нас был основной "шаблонный" репозиторий, который склеил все компоненты и несколько других репозиториев GIT для каждого из них.
  5. Наконец, мы разрабатываем легкую систему тем (в основном загружаем /stylesheets/themes/: theme_name/и получаем имя темы из БД). Поскольку это проект интрасети, мы могли бы почти что-либо сделать с правильным стилем CSS. Я бы предположил, что для работы с IE вам потребуется более сложный подход.
  6. Затем мы просто использовали этот основной репозиторий, разрабатывающий новые функции поверх него.

Теперь, как мы имеем дело с изменениями в базовой базе. Мы начинаем с нашего репозитория шаблонов. Мы фиксируем или определяем, где должно быть исправление или изменение, либо либо изменить его там, либо на нем соответствующий gem/plugin. После надлежащего тестирования, мы разворачиваем его в нашу учетную запись GitHub.

Наконец, мы объединяем/переустанавливаем другие проекты из этого репозитория шаблонов, получая новые обновления.

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

Ответ 2

При минимальном касании основного сайта может быть возможно использовать код Ruby, расширяя шаблоны и изменяя стили. Я много работал над Django, и макет может выглядеть так:

project/
    sites/
        site_one/
            templates/
            models.py
            settings.py
            urls.py
            views.py
        site_two/
            templates/
            models.py
            settings.py
            urls.py
            views.py
    base_app/
    settings.py

Вы можете попробовать сделать что-то подобное в Rails:

main_webapp/
    app/
    config/
    ...
    sites/
        site_one/
            controllers/
            models/
            views/
        site_two/
            controllers/
            models/
            views/

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

Django также имеет понятие Sites и способность искать шаблоны в одной конкретной папке проекта и папке приложения. Вы можете попытаться скопировать эти функции и перенести их в Rails, чтобы выполнить запуск нескольких сайтов с одной базы.

Я понимаю, что вы ищете решение Rails, но вы все равно можете проверить, как это делается в Django, и скопировать некоторые полезные функции на другую сторону. Если мне нравится функция Rails, я переношу ее на Django/Python.

Ответ 3

Мы делаем что-то подобное в моей компании. Кроме того, что в настоящее время он включает несколько сред (производство, тестирование, разработка). Мы используем SVN в качестве нашего SCM, чтобы поддерживать наш код, и позволяет нам дублировать текущую стабильную среду и создавать отдельные версии приложения (и, возможно, изменять такие вещи, как логотипы или определенные функции). Я настоятельно рекомендую запускать среду с Apache/Nginx и Phusion Passenger. Это позволяет нам запускать все эти приложения отдельно, на одной и той же/подобной кодовой базе. И это так. У нас есть DB, один Production и One Development, чтобы поддерживать наши данные в реальном времени отдельно, но вы можете легко подключить два экземпляра приложения к одному и тому же db таким образом. На данный момент это очень хорошо зарекомендовало себя для разработки, тестирования и развертывания нескольких веб-приложений без снятия основного производственного сервера.