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