Запустите настроенную версию приложения Rails

Question

Вот наши основные требования:

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

Для этого я вижу несколько вариантов достижения этой цели:

• Git branch
• Rails::Engine
• Rails::Application

Наиболее очевидным ответом будет Git branch для полной гибкости.

Однако я не уверен, что это хорошая идея, потому что кодовая база в значительной степени разделяется, а основная строка имеет многобольше действий - наверстать упущенное с помощью rebase / merge.

Мы хотим максимально разделить оригинальную и настроенную версии.Другими словами, мы хотим, чтобы как можно реже возникали конфликты между оригиналом и настроенным.

Rails::Engine или Rails::Application казалось близкой идеей (я не знаком с Rails Engines),но я не понимаю, как иметь OurApp::Application и OurCustomizedApp::Application в одном месте и переключаться между ними глобально и динамически.

Возможно, было бы неплохо иметь:

• пользовательские инициализаторы, контроллеры и представления в отдельном каталоге для переопределения (или исправления) исходной
• возможности указать, какое приложение (оригинальное или настроенное) загружать с помощью переменной среды, такой как RAILS_APP
• отдельные файлы конфигурации, например так: config/database.yml будет config/customer1/database.yml
• возможность использовать тот же deploy.rb для capistrano (возможно, с config/servers.yml и config/customer1/servers.yml для определения ролей и IP-адресов?)

Существуют ли практики / соглашения для наших требований?Любой совет?

Наши приложения работают на Ruby 1.9.2 + Rails 3.0.3.

ОБНОВЛЕНИЕ

Мы запустили его как ветку Git.Мы создали задачу rake для генерации файла в config/branch, который содержит текст типа «master» или «custom», и application.rb читает его при начальной загрузке.Конфиги типа database.yml или servers.yml теперь находятся в config/mainline/ или config/customized/, и application.rb обрабатывает их соответственно.

config.paths.config.database = "config/#{branch}/database.yml"

Не идеально, но пока достаточно.Я обновлю, когда мы найдем лучший способ сделать это.

Answer 1

Я думаю, что лучший подход - это делать по старинке.

Сначала добавьте в ваш проект одноэлементный класс (в /lib), который называется что-то вроде Affiliate.Этот класс должен предоставлять реализации по умолчанию (все, что вы хотите, чтобы ваше базовое приложение использовало) для любых частей приложения, которые могут быть настроены.На этом этапе ваше приложение функционирует так же, но имеет хуки для настройки.

На сайте вашего клиента разверните тот же исходный код (может быть, поставляется как гем), но также разверните плагин Rails, которыйпереопределяет Affiliate, поэтому его метод singleton instance возвращает пользовательский подкласс, который предоставляет специфическую для клиента информацию или поведение.

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

Answer 2

Кажется, у вас есть два интересных требования здесь.Вы спрашиваете, как иметь два отдельных приложения и динамически переключаться между ними.Я предполагаю, что вы хотите разместить разные «версии» одного и того же приложения и сделать так, чтобы приложение переключалось на разные настройки в зависимости от домена.Однако это сильно отличается от использования веток Git для развертывания двух разных приложений.

Можете ли вы уточнить здесь свои требования?

Я бы не рекомендовал Git ветки в качестве решения здесь.Я бы порекомендовал использовать двигатели.Особенно встраивая ваш движок в драгоценный камень.

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

Таким образом вы сохраняете все различия, изложенные в отдельном проекте.Этот отдельный проект также будет иметь свой собственный набор тестов и т. Д.

Answer 3

Я знаю, что это не точный ответ, который вам нужен, но я думаю, что Git будет наименьшим объемом работы - и самым простым в управлении, долгосрочным - по сравнению с настройкой приложения и добавлением логики для обработки дополнительных файлы конфигурации, изменение файлов развертывания, а также управление (потенциально) новыми файлами css / js / template.

Использование rebase & merge будет намного менее подвержено ошибкам, и до тех пор, пока вы регулярно синхронизируете свои ветви, у вас не должно быть серьезных проблем с поддержанием их обоих в актуальном состоянии. В конце концов, это то, в чем Git хорош! ;)

Answer 4

Мы используем Git, чтобы делать это довольно часто.