Cómo gestionar las diferencias utilizando la misma base de código para varios sitios web de Rails 2.3

Tenemos un website que utiliza Rails 2.3.x, bundler, nginx, passenger y git, y ahora nos gustaría utilizar el mismo código para implementar un sitio muy similar. Las diferencias entre los dos includeán:

  • Lugar
  • Bases de datos
  • Validaciones en algunos casos
  • Vistas en algunos casos

¿Cuál es la mejor manera de gestionar estas diferencias utilizando la misma base de código?

Algunas ideas que hemos tenido:

  • Cree nuevos entornos de Rails, como production-a y production-b, y maneje las diferencias en los files de entorno apropiados. Un posible problema es que muchas gems y complementos están codificados para search entornos de producción o desarrollo .

  • Use Passenger para establecer una variable global o use el dominio por request para determinar qué context usar. El problema con esto son las tareas de rake, cron, etc. que no tendrían acceso a este estado.

  • Mantenga dos versiones del directory config. Esto sería inconveniente manteniendo 2 versiones de todo el file de configuration, muchas de las cuales serían idénticas. Además, ahora estoy seguro de cómo aprovechar git para hacer esto correctamente.

¡Cualquier idea, consejo o ejemplo sería muy apreciado! La pregunta n. ° 6753275 está relacionada pero parece incompleta.

Una solución que he usado en un proyecto de carriles 2.3.x fue convertir todo el sitio a un engine . Eso en realidad es bastante fácil, crea una carpeta en el vendor\plugins\ y mueve todo el material de la app allí. Puedes ver una explicación para los carriles 2.3 aquí .

Si es necesario, puede mover todas las migraciones y cosas así, y usar una tarea de rake para ejecutarlas.

Todo lo que necesita ser anulado puede entonces simplemente colocarse en el proyecto de Rails reales utilizando el motor. Por lo tanto, tendría dos proyectos de raíles, con su propia configuration, configuraciones regionales y algunas reglas generales locales, y un gran complemento / motor compartido.

Usamos git submodules para mantener el código sincronizado en diferentes proyectos.

En los Rails 3 esto es aún más fácil, ya que el motor ahora puede ser solo una joya.

Espero que esto ayude.