Question

We have a website using Rails 2.3.x, bundler, nginx, passenger and git, and would now like to use the same code to deploy a very similar site. Differences between the two will include:

• Locale
• Databases
• Validations in some cases
• Views in some cases

What is the best way to manage these differences while using the same code base?

Some ideas we’ve had:

• Create new Rails environments, such as production-a and production-b and handle differences in the appropriate environment files. One potential problem is that many gems and plugins are hardcoded to look for production or development environments.

• Use Passenger to set a global variable or use the domain per request to determine which context to use. The problem with this are rake tasks, cron jobs, etc that would not have access to this state.

• Maintain two versions of the config directory. This would be inconvenient maintaining 2 versions of all the config file, many of which would be identical. Also, I’m now sure how to leverage git to do this correctly.

Any ideas, tips, or examples would be greatly appreciated! Question #6753275 is related but seems incomplete.

Answer 1

One solution I have used in a rails 2.3.x project was to convert the entire site to an engine. That actually is pretty easy, create a folder under vendor\plugins\ and move all the app stuff there. You can see an explanation for rails 2.3 here.

If needed you can even move all migrations and stuff there as well, and use a rake task
to run those.

Everything that needs to be overruled can then just be placed in the actual rails project using the engine. So you would have two rails-projects, with their own configuration, locales and some local overrules, and one big shared plugin/engine.

We used git submodules to keep the code in sync over different projects.

In rails 3 this is even easier, since the engine can now just be a gem.

Hope this helps.