Shared models between two Rails apps - what is the ideal solution for Workflow?

Question

I am currently working on a Rails 3 project that is divided up into four parts:

• The public facing website
• The administration website/backend

Answer 1

You can create a mountable engine that contains the shared models and create a gem out of it. This will handle the name spacing issues elegantly. Other nice aspect here is you get to share your assets also.

Watch this railscast for more details.

Answer 2

Take look at Git subtree.

This may work for you..

http://igor-alexandrov.github.io/blog/2013/03/28/using-git-subtree-to-share-code-between-rails-applications/

OR

You can write Rake task..

Example:-

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

See the below link.

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

Answer 3

You'll still have to manage the 'versions' by pushing changes that need to be tested to a remote repo, but you can use the new local config of Bundler 1.2

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

This way it will pick up your local commits and you won't have to keep change your Gemfile upon deployment.

Answer 4

drop the models project(put models into one of other parts, i'd suggest whatever you consider "more important"), put all projects into single repository(separate project folders) and make symlinks to models/libs/apis/whatever

your code is highly coupled together and you often need to make changes to few projects at once(like updating models and updating APIs that use them, etc)

one nice thing about single-repo-symlink setup is that your commits will be less fragmented and will usually represent full feature implementation - easier to track bugs, read history and maintain codebase

also when you deploy you don't need to read from many repositories - one less point of failure right there

release process is also simpler with such model as branch will now hold the scope of all projects

there are some drawbacks like symlinks dont work that well on windows and whatnot but for me it works perfectly

Answer 5

I know that this is not an solution for your particular problem. But I really suggest you to merge all projects into one. It is very usual to have all this parts in one application and there is no overhead. I think there is no not-awkward solution for this problem.

Answer 6

Does your project have enough code coverage? If it does, I would try to separate the logic where it makes sense, and if a model is used in different projects, just pick one that fits best and write an API on top of that.

Then you could use that API to access those models (preferably using something like ActiveModel) on the other project. You would still have a simple CRUD, but all the core model logic would be handled externally.

Be sure to think well before splitting them up, though. You want to keep your domain tight on each app you create out of the Behemoth you want to torn apart.

Regarding engines:

I have used Engines for the same issue and it does help, but I also had to change my Gemfile to either point to a local path when developing, pushing the gem, then pulling it on the current project, which is the behavior you're not fond of.