単一のRailsアプリの一部であるが、いくつかの異なる「モード」で使用されるコードをどのように処理するのが最適ですか？
同じデータソース（MySQL、MongoDB、SOLR）から駆動され、コアロジック、アセットなどを複数の異なる用途で共有するアプリには、いくつかの異なるケースがあります。
背景/詳細：
HTMLとRESTAPI
一般的なシナリオは、HTMLとRESTのインターフェースがあることです。これらの違いは、ルーティング（/api/v1/user/newvs/user/newなど）によって処理されます。わずかな違いはありますが、同じ機能を提供します。これは私にはかなりきれいに思えます。
マルチテナント
もう1つの一般的なシナリオは、アプリが「マルチテナント」であり、主にURLのサブドメイン（partner1.example.comやpartner2.example.com（またはAPIカスタマーのクエリ文字列パラメーター）など）によって決定されることです。異なる機能またはプロパティがいくつかあります。ApplicationControllerこれは、メソッドによってカプセル化されたテナント固有の機能を備えたテナント固有のデータベーステーブルのセットに主に格納されているデータを使用するフィルターによって処理されます。これも私にはかなりきれいに思えます。
オフラインタスク
1つのシナリオは、フィードローダー、スクレーパー、クローラー、およびこの種の他のタスクなど、非常に多くのタスクを介して大量のデータが取得され、ほぼ継続的に実行されることです。私たちが行うことの大部分である検索エンジンで。rakeこれらのタスクはアイドル状態のサーバーインスタンスで起動され、定期的に実行されます...ただし、アプリの一部であるタスクに すぎません。
これらのタスクは、フロントエンドコードとは特徴的に異なります。データの更新、計算の実行、メンテナンスタスクの実行などです。一部のタスクは数日間実行されます（たとえば、外部Webサービスからの30Mドキュメントの更新）。最終的に、これらのタスクは、フロントエンドアプリが使用するコアデータを作成して最新の状態に保ちます。
これは私にはそれほどきれいではないようです。特に、場合によっては、これらのタスクが実行され、アプリケーションがそれらを使用しているのと同時にデータの更新を行っているため、フロントエンドアプリに従わなければならないことがあります。 'ピーク負荷の下にあります。
アプリの主なバリエーション この最後のケースは明らかに間違っています-ブランチを作成して完全に別個のアプリとして実行し、コアデータの一部を共有することで、アプリの主要なカスタマイズを15％または20％変更しました。しかし、それ以外の場合は独自のデータの一部を使用します。もちろん、これは受け入れられないので、私たちは今これをほとんど修正しました。
OK、ここのどこかに質問がありますよね？
したがって、特にオフラインタスクの場合、アプリは実際には「モード」またはおそらく「サブ環境」で起動する必要があると思います。ただし、独自の分離データやその他の構成パラメーターを持つ通常の開発、テスト、qa、デモ、pre_release、本番環境はまだあります。これらのそれぞれについて、アプリケーションのさまざまな「モード」を実行、開発、テスト、および展開できるようにする必要があります。
標準のRails環境の宣言型の概念に似た適切なアーキテクチャを誰かが提案できますか？