两个 Rails 应用程序之间的共享模型 - 工作流的理想解决方案是什么？

Question

我目前正在开发一个 Rails 3 项目，该项目分为四个部分：

• 面向公众的网站
• 管理网站/后端
• 模型
• 用于第三方数据访问的 API

由于模型在三个关键组件之间共享，我想保留它们远离一个主要项目，但是每个部分都需要访问模型，但我不想重复代码并且到处都有不同的版本。

目前，我在 gem 中拥有模型代码，并且在每个项目的 Gemfile 中，我使用以下行引用它们：

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

但是，当我部署到测试服务器以供同事评估系统时，我需要从外部存储库，因此我将上面的行替换为以下内容：

gem "my_models", :git => "[email protected]:username/my_models.git"

这本身运行良好，但在“版本”方面相当笨重（即，每次我希望将更改部署到测试时，我都需要更改版本）服务器），切换线路使用 git 而不是 local，并确保我正确推送文件。

以前我使用共享 git 子模块，但这同样尴尬。

我宁愿不将所有内容都构建到一个大型项目中，因为这些项目往往会变得巨大且难以维护，并且如果可能的话，我也希望将关注点分开，因此我对管理站点所做的任何更改都没有太大的影响有机会影响其他组件 - 显然这些模型有可能导致问题，但这是我已经考虑和理解的风险。

当谈到这样的事情时，人们会提出什么建议？或者，我的处理方式完全错误吗？

一些额外的背景：

这个应用程序是对现有网站的重写，该网站遵循“将所有内容集中到一个项目中”的模型 - 不幸的是这里有两个问题：

1. 该应用程序开发得很糟糕 - 我继承了这个项目，当我第一次拿起它时，单个用户每页的加载时间约为 2 分钟 - 此后该时间已减少，但整个过程中仍然存在问题
2. 我们目前已达到当前站点的容量限制，我们预计我们将需要在接下来的 6 个月内承担更多负载 - 但是扩展使用“一体化”应用程序意味着我们将浪费资源来扩展不需要它的网站后端。

本质上有两件事我想分开 - 前端（公共网站和 API）和后端 - 我对软件开发的了解告诉我，将所有这些结合在一起并不是一个理想的解决方案（过去的历史表明我认为将这两者分开对于确保前端性能来说是一个很好的举措）。

也许我需要从另一个角度来看待这个问题 - 将模型保留在每个项目中，而不是在项目之间共享它们，而是为每个功能区域提供一个缩减的功能子集（即后端需要知道谁创建了帖子，但是前端并不真正关心这一点，因此在读取模型时忽略该逻辑）。

Answer 1

删除模型项目（将模型放入其他部分之一，我建议您认为“更重要”的任何内容），将所有项目放入单个存储库（单独的项目文件夹）并创建指向 models/libs/apis/无论

您的代码的 符号链接高度耦合在一起，您经常需要同时对几个项目进行更改（例如更新模型和更新使用它们的 API 等）

单存储库符号链接设置的一个好处是您的提交将减少碎片化并且通常会代表完整的功能实现 - 更容易跟踪错误，读取历史记录和维护代码库，

而且当您部署时，您不需要从许多存储库中读取 - 那里的故障点更少，

使用分支这样的模型发布过程也更简单现在涵盖了所有项目的范围，

有一些缺点，比如符号链接在 Windows 上不能很好地工作，但对我来说它工作得很好

Answer 2

您可以创建一个包含共享模型的可安装引擎，并用它创建一个 gem。这将优雅地处理名称间距问题。这里的另一个好处是您也可以分享您的资产。

观看railscast 了解更多详情。

Answer 3

您仍然需要通过将需要测试的更改推送到远程存储库来管理“版本”，但您可以使用 Bundler 1.2

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

这样它将获取您的本地提交，而您不必保留部署时更改 Gemfile。

Answer 4

我知道这不能解决您的特定问题。但我真的建议你将所有项目合并为一个。将所有这些部分包含在一个应用程序中是很常见的，并且没有任何开销。我认为这个问题没有不尴尬的解决方案。

Answer 5

看一下 Git 子树。

这可能对你有用..

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

或者

你可以编写 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 6

您的项目有足够的代码覆盖率吗？如果确实如此，我会尝试将有意义的逻辑分开，如果一个模型用于不同的项目，只需选择一个最适合的模型并在其之上编写一个 API。

然后，您可以使用该 API 访问其他项目上的这些模型（最好使用 ActiveModel 之类的东西）。您仍然会有一个简单的 CRUD，但所有核心模型逻辑都将在外部处理。

不过，在分开它们之前一定要三思而后行。您希望在您想要拆分的庞然大物中创建的每个应用程序上保持严格的域。

关于引擎：

我已经使用 Engines 来解决同样的问题，它确实有帮助，但我还必须将 Gemfile 更改为在开发时指向本地路径，推送 gem，然后将其拉到当前项目上，这就是行为你不喜欢。