Совместно используемые модели между двумя приложениями Rails - какое идеальное решение для Workflow?

Question

В настоящее время я работаю над проектом Rails 3, который разделен на четыре части:

• Общедоступный веб-сайт
• Административный веб-сайт / серверная часть
• Модели
• API для доступа к данным сторонних производителей

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

В настоящее время у меня есть код модели в геме, и в Gemfile каждого проекта я ссылаюсь на них следующимстрока:

gem "my_models", :path => "../my_models/"

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

gem "my_models", :git => "git@private.repository.com:username/my_models.git"

Само по себе это работает хорошо, но довольно «неуклюже» с точки зрения «версий» (т.е. мне нужно поднимать версию каждый раз, когда я хочу развернутьизменения на тестовых серверах), переключите линию, чтобы использовать git вместо локального, и убедитесь, что я правильно отправляю файлы.

Ранее я использовал общий подмодуль git, но это было так же, какнеловко.

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

Что бы люди там предложили, когда этоприходит что-то подобное?Или я поступаю совершенно неправильно?

Некоторые дополнительные сведения:

Это приложение переписано на существующий веб-сайт, который следует модели «кома».все в один проект »- к сожалению, здесь есть две проблемы:

1. Приложение было плохо разработано - я унаследовал этот проект, и когда я впервые поднял его, время загрузки составляло ~ 2 минуты на страницу сдля одного пользователя - с тех пор этот показатель сократился, но все еще возникают проблемы в течение
2. . В настоящее время мы достигли предела пропускной способности текущего сайта и ожидаем, что нам потребуется больше нагрузки в течение следующих 6 месяцев - однакомасштабирование с помощью приложения «все в одном» означает, что мы будем тратить ресурсы на масштабирование серверной части сайта, которая ему не нужна.

По сути, я хочу сделать две вещиотдельный - интерфейс (являющийся общедоступным веб-сайтом и API) и серверная часть - все, что я знаю о разработке программного обеспечения, говорит мне, что объединениевсе это вместе не является идеальным решением (и прошлая история показывает, что разделение этих двух элементов является хорошим шагом с точки зрения обеспечения производительности интерфейса).

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

Answer 1

удалите проект моделей (поместите модели в одну из других частей, я бы посоветовал все, что вы считаете "более важным"), поместите все проекты в один репозиторий (отдельные папки проектов) и создайте символические ссылки на модели / libs / apis /

ваш код тесно связан друг с другом, и вам часто приходится вносить изменения сразу в несколько проектов (например, обновлять модели и обновлять API, использующие их и т. д.)

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

также при развертывании вы ненужно читать из многих репозиториев - на одну меньшую точку сбоя прямо сейчас

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

есть некоторые недостатки, такие как символические ссылкине работает, что хорошо на окнах и еще много чего, но для меня это работает отлично

Answer 2

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

Смотрите это railscast для более подробной информации.

Answer 3

Вам все равно придется управлять «версиями», выдвигая изменения, которые необходимо протестировать, в удаленное хранилище, но вы можете использовать новую конфигурацию local в Bundler 1.2

http://gembundler.com/man/bundle-config.1.html#LOCAL-GIT-REPOS

Таким образом, он будет принимать ваши локальные коммиты, и вам не придется постоянно менять Gemfile при развертывании.

Answer 4

Взгляните на Git поддерево.

Это может сработать для вас ..

http://igor -alexandrov.github.io / блог / 2013/03/28 / с использованием-ГИТ-поддерево к -доле-коде, между рельсами-приложениями /

OR

Вы можете написать задание Rake.

Пример: -

namespace :sync do

  desc 'Copy common models and tests from Master'
  task :copy do
   source_path = '/home/project/src-path'
   dest_path = '/home/project/dest-path'

   # Copy all models & tests
   %x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/}
   %x{cp #{source_path}/spec/models/*_spec.rb #{dest_path}/spec/models/}

   # Database YML
   %x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml}

end

См. Ссылку ниже.

http://hiltmon.com/blog/2013/10/14/rails-tricks-sharing-the-model/

Answer 5

Достаточно ли у вашего проекта покрытия кода?Если это так, я бы попытался отделить логику там, где это имеет смысл, и если модель используется в разных проектах, просто выберите ту, которая подходит лучше всего, и напишите API поверх этого.

Тогда вы могли бы использовать этот API для доступа к этим моделям (предпочтительно используя что-то вроде ActiveModel) в другом проекте.У вас все еще будет простой CRUD, но вся логика базовой модели будет обрабатываться извне.

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

Относительно движков:

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

Answer 6

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