Запуск специальной версии приложения Rails

Question

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

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

Чтобы сделать это, я могу видеть несколько вариантов для достижения этой цели:

• Git филиал
• Rails::Engine
• Rails::Application

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

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

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

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

Вероятно, было бы неплохо иметь:

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

Есть ли практика/конвенции для наших требований? Любой совет?

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

UPDATE

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Опишите здесь вас следующие требования:

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

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

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