Rails的“子环境” - 仍然生产（或测试等），但不同

Question

我们应该如何最好地处理单个Rails应用程序的一部分，但在几种不同的“模式”中使用的代码？

我们有几种不同的应用程序，它们是由相同的数据源（MySQL，MongoDB，SOLR）驱动的，并在多种不同用途中共享核心逻辑，资产等。

背景/详细信息：

HTML VS 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，演示，预发布，生产环境，这些环境有其自己的隔离数据和其他配置参数。对于其中的每一个，我们都希望能够运行，开发，测试和部署应用程序的各种“模式”。

任何人都可以提出一个类似于标准Rails环境的声明性概念的适当架构吗？

Answer 1

• 如果模式的数量不断增加：

  也许脱机任务可以从主应用程序（分离成他们自己的应用程序或实际的任务从它继承父抽象的任务，单独部署）。

• 如果模式的数量相对较小，不会经常发生变化：

  你可以把每模式配置成一个配置文件，在逻辑上从代码的其余部分分开。然后在部署期间，您将能够提供（环境，模式，主机集合）的组合并获得对环境的良好控制，而使用相同的代码库。