architecture - Rails "sub-environment" -- still production (or test, etc.) but different -

how should best handle code part of single rails app, used in several different "modes"?

we have several different cases of app driven same data sources (mysql, mongodb, solr) , shares core logic, assets, etc. across multiple different uses.

background/details:

html vs rest api common scenario have html , rest interfaces. these differences handled through routing (e.g. /api/v1/user/new vs /user/new) -- minor differences provide same functions. seems reasonably clean me.

multi-tenant common scenario app "multi-tenant", determined subdomain of url, e.g. partner1.example.com , partner2.example.com (or query-string parameter api customers) -- each has number of features or properties differ. handled filter applicationcontroller using data largely stored in set of tenant-specific database tables tenant-specific functionality encapsulated methods. seems reasonably clean me.

offline tasks 1 scenario great deal of data acquired through large number of tasks, running pretty continuously: feed loaders, scrapers, crawlers, , other tasks of sort ... kinds of things find in search engine, large part of do. these tasks launched on idle server instances , run periodically ... rake tasks part of app.

these tasks characteristically different our front-end code -- update data, run calculations, maintenance tasks , on -- tasks run days (e.g. update 30m documents external web service). in end, these tasks create , keep fresh core data our front end app uses.

this 1 doesn't seem clean me, in particular, in cases, these tasks running , doing data updates @ same time our application using them, need defer front-end app when we're under peak loads.

major variants of app last case wrong -- have made major customizations of our app -- 15% or 20% different, making branches , running entirely separate app, sharing of core data sometimes, using of own data other times. have fixed now, was, of course, untenable.

ok, there's question in here somewhere, right?

so in particular offline tasks feel app needs launched in "mode" or perhaps "sub-environment". still have normal development, test, qa, demo, pre_release, production environments have own isolated data , other configuration parameters. each of these, want able run, develop, test , deploy various "modes" of application.

can suggest appropriate architecture similar declarative notions of standard rails environments?

• if number of modes ever-increasing:

  perhaps offline tasks separated main app, own application (or parent abstract task actual tasks inheriting , deployed individually).

• if number of modes relatively small , won't changing often:

  you put per-mode configuration config file, logically separate rest of code. during deployments, able provide combination of (environment, mode, set of hosts) , level of control of environments while using same codebase.