我们应该如何最好地处理属于单个Rails应用程序的代码，但是在几种不同的“模式”中使用？
我们有几个不同的应用案例，它们来自相同的数据源（MySQL，MongoDB，SOLR），并在多种不同的用途中共享核心逻辑，资产等。
背景/细节：
HTML与REST API
常见的情况是我们有HTML和REST接口。这些差异是通过路由处理的（例如/api/v1/user/new vs /user/new） - 它们之间存在细微差别，它们提供相同的功能。这对我来说似乎相当干净。
多租户
另一种常见情况是应用程序是“多租户”，主要由URL的子域确定，例如， partner1.example.com和partner2.example.com（或API客户的查询字符串参数） - 每个都有许多不同的功能或属性。这由过滤器ApplicationController使用主要存储在一组特定于租户的数据库表中的数据来处理，这些数据库具有由方法封装的特定于租户的功能。对我来说这似乎也相当干净。
脱机任务
一种情况是，大量的数据是通过大量的任务获得的，这些任务连续运行：饲料装载机，铲运机，爬虫和其他类似的任务...你会发现的一些事情。搜索引擎，这是我们所做的很大一部分。这些任务在空闲服务器实例上启动并定期运行......但只是rake任务是应用程序的一部分。
这些任务在特征上与我们的前端代码不同 - 它们更新数据，运行计算，执行维护任务等等 - 某些任务运行数天（例如，从外部Web服务更新30M文档）。最后，这些任务创建并保持我们的前端应用程序使用的核心数据。
这个对我来说似乎并不干净，特别是在某些情况下，这些任务正在运行并在我们的应用程序使用它们的同时进行数据更新，因此偶尔需要遵循前端应用程序在我们处于峰值负载时。
应用程序的主要变体 最后一个案例显然是错误的 - 我们通过制作分支机构然后作为一个完全独立的应用程序运行，对我们的应用程序进行了主要定制 - 15％或20％不同，有时共享一些核心数据，但使用了一些自己的数据其他时间。我们现在大部分已经修好了，因为它当然是站不住脚的。
好的，这里有个问题，对吧？
因此，特别是对于离线任务，我觉得应用程序确实需要在“模式”或“子环境”中启动。但我们仍然有正常的开发，测试，qa，demo，pre_release，生产环境，它们有自己的隔离数据和其他配置参数。对于其中的每一个，我们希望能够运行，开发，测试和部署应用程序的各种“模式”。
任何人都可以建议一个与标准Rails环境的声明性概念类似的适当架构吗？
答案 0 :(得分：1)
如果模式数量不断增加：
也许离线任务可以从主应用程序分离到他们自己的应用程序（或父实例任务，其中实际任务继承并单独部署）。
如果模式的数量相对较小并且不会经常变化：
您可以将每模式配置放入配置文件中，逻辑上与其余代码分开。然后在部署期间，您将能够提供（环境，模式，主机集）的组合，并使用相同的代码库在时获得对环境的良好控制。