Выполнение нескольких сайтов от той же кодовой базы направляющих?
SQL Server 2005 и предлагает MVCC как опцию; это не значение по умолчанию, как бы то ни было. MS называет его изоляцией снимка, если не изменяет память.
3 ответа
В настоящее время мы работаем с настройкой, очень похожей на то, что вы описываете.
Мы начали разработку довольно большого приложения Rails (продажи, управление запасами, каталог продуктов и т.д.) для клиента. После его доработки появилось несколько новых запросов на практически идентичный функционал.
Однако исходное приложение пришлось поддерживать, добавляя новые функции, исправляя ошибки и многое другое.
Расширенные требовались для поддержания большей части функциональности, но меняли внешний вид и внешний вид.
Мы выполнили ряд шагов:
- Сначала мы начали очищать код, извлекая ссылки жесткого кода на таблицы, оптимизация запросов, поиск недостающих индексов и способы улучшить использование ActiveRecord
- . После некоторого удовлетворения мы начали разработку недостающих тестов. Я не могу не подчеркнуть, почему это? Это полезно, так как мы будем поддерживать одну и ту же кодовую базу для нескольких приложений, а основные функции должны быть максимально защищены от новых изменений.
- Это также было волшебное слово: основные функции. Мы начали выбирать базовые функции, которые можно было бы использовать повторно, и извлекать весь общий код. Это дало нам сочетание контроллеров, моделей и представлений, которые мы начали преобразовывать в модули, плагины и гемы.
Что куда? Сильно зависит от вашего кода. Как правило, функциональность, не связанная с языком домена, передается плагинам (или драгоценным камням, если это не слишком сильно зависит от Rails)
- Этот подход привел нас к нескольким плагинам, гемам, которые мы затем собрали вместе, повторно собрав исходный проект, а затем он попал в собственный репозиторий GIT. Таким образом, у нас был главный репозиторий «шаблонов», в который были склеены все компоненты, и несколько других репозиториев GIT для каждого из них.
- Наконец, мы разрабатываем простую систему тем (в основном загружаем / stylesheets / themes /: theme_name / и получаем theme_name из БД). Поскольку это проект интрасети, с правильным стилем CSS мы могли бы делать что угодно. Я предполагаю, что для работы с IE вам понадобится более сложный подход.
- Затем мы просто использовали этот главный репозиторий, разрабатывая новые функции на его основе.
Теперь, как нам поступить с изменениями в основная база. Начнем с нашего репозитория шаблонов. Мы исправляем или определяем, где должно быть исправление или изменение, и либо меняем его там, либо в соответствующем геме / плагине. После надлежащего тестирования мы развертываем его в нашей учетной записи GitHub.
Наконец, мы объединяем / перебазируем другие проекты из этого репозитория шаблонов, получая новые обновления.
Звучит немного сложно, но это было только для настройки . Текущий рабочий процесс довольно прост и удобен, с данным преимуществом работы с несколькими разработчиками без серьезных проблем.
с данным преимуществом работы с несколькими разработчиками без больших проблем. с данным преимуществом работы с несколькими разработчиками без больших проблем.Мы делаем нечто подобное в моей компании. За исключением того, что в настоящее время задействовано несколько сред (производство, тестирование, разработка). Мы используем SVN в качестве нашего SCM, чтобы наш код оставался ясным и позволял нам дублировать текущую стабильную среду и создавать отдельные версии приложения (и потенциально изменять такие вещи, как логотипы или определенные функции). Я настоятельно рекомендую запустить среду с Apache / Nginx и Phusion's Passenger . Это позволяет нам запускать все эти приложения по отдельности на одной и той же / аналогичной кодовой базе. И это все. У нас есть базы данных, одна производственная и одна разработка, чтобы наши живые данные были разделены, но вы можете легко подключить два экземпляра приложения к одной и той же базе данных. До сих пор это работало для нас очень хорошо, поскольку мы могли развиваться,
С минимальным прикосновением к основному сайту можно было бы использовать код 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 также имеет концепцию сайтов и возможность искать шаблоны в одной конкретной папке проекта и папке приложения. Вы можете попытаться скопировать эти функции и перенести их в Rails, чтобы обеспечить запуск нескольких сайтов из одной кодовой базы.
Я понимаю, что вы ищете решение Rails, но вы все равно можете проверить, как это делается в Django, и скопировать некоторые из полезные функции на другую сторону. Если мне нравится какая-то особенность Rails, я портирую ее на Django / Python.