¿Se ejecutan varios sitios desde la misma base de código de rieles?

Question

Tengo un cliente que quiere tomar su aplicación Rails que ha sido exitosa en un nicho y aplicarla a otro nicho similar. Esta nueva instancia de la aplicación va a comenzar muy similar: todas las mismas funcionalidades, diferentes logotipos y colores. Sin embargo, si el nuevo sitio tiene éxito, inevitablemente necesitará personalizaciones significativas que no deberían aplicarse al sitio original. Al mismo tiempo, si se solucionan los errores y se realizan mejoras en una aplicación, ambas aplicaciones deberían poder compartir esas mejoras.

¿Alguien puede sugerir estrategias o recursos que resuelvan este problema? ¿Cómo puedo evitar que los cambios que se aplican a ambas aplicaciones tomen más tiempo para probar e implementar?

Sí, sé que la respuesta implica SCM, complementos, gemas y motores Rails. Estas herramientas serán y serán usadas. pero quiero saber cuando y cómo utilizar estas herramientas para resolver este problema.

Los enlaces también son bienvenidos.

---

Esta pregunta no es lo mismo que:

Multiple websites running on same codebase? En mi pregunta, no estoy corriendo la misma aplicación exacta con diferentes configuraciones.

How do you sync changes between multiple codebases? Estoy haciendo una pregunta similar, pero estoy preguntando específicamente sobre las aplicaciones de Rails.

Answer 1

Actualmente trabajamos con una configuración bastante similar a la que está describiendo.

Comenzamos a desarrollar una aplicación de Rails algo grande (ventas, gestión de stock, catálogo de productos, etc.) para un cliente. Después de terminarlo, llegaron varias solicitudes nuevas de funcionalidad casi idéntica.

La aplicación original, sin embargo, tuvo que mantenerse, agregar nuevas funciones, corregir errores y todo eso.

Los extendidos necesarios para mantener la mayor parte de la funcionalidad, pero cambian el aspecto y el aspecto.

Lo que hicimos fue seguir una serie de pasos:

1. Primero comenzamos a limpiar el código, tirando referencias codificar a las tablas, reducir y optimizar las consultas, mirando hacia arriba índices que faltan y las maneras de mejorar nuestro uso de ActiveRecord
2. Después de estar algo satisfechos, comenzamos a desarrollar pruebas faltantes.No puedo hacer suficiente hincapié en por qué es útil, ya que mantendremos una misma base de código para varias aplicaciones, y necesitamos que la funcionalidad principal esté lo más protegida posible de los cambios nuevos.
3. Esa fue también la palabra mágica: funcionalidad central. Comenzamos a seleccionar la funcionalidad básica que podría reutilizarse y a la extracción de todo el código genérico. Eso nos dio una combinación de controladores, modelos y vistas, que comenzamos a cambiar en módulos, complementos y gemas. ¿Qué va a dónde? Depende mucho de tu código. Como regla general, la funcionalidad que no trata con el lenguaje de dominio va a los complementos (o gemas si no depende demasiado de los rieles)
   4. Este enfoque nos llevó a varios plugins, gemas que luego reunimos para volver a ensamblar el proyecto original, y luego llegó a su propio repositorio de GIT. De esta forma, teníamos un repositorio principal de "plantilla" que pegaba todos los componentes y varios otros repositorios GIT para cada uno de ellos.
   5. Finalmente, desarrollamos un sencillo sistema de temas (básicamente cargando/stylesheets/themes /: theme_name/y obteniendo theme_name de la base de datos). Como se trata de un proyecto de intranet, casi podríamos hacer cualquier cosa con un estilo CSS adecuado. Supongo que para trabajar con IE necesitarías un enfoque más complejo.
   6. Luego, simplemente usamos ese repositorio principal desarrollando la nueva funcionalidad en la parte superior.

Ahora, ¿cómo podemos hacer frente a los cambios en la base central. Comenzamos con nuestro repositorio de plantillas. Arreglamos o definimos dónde debería estar la corrección o el cambio y lo cambiamos allí o en su joya/complemento correspondiente. Después de probarlo adecuadamente, lo implementamos en nuestra cuenta de GitHub.

Finalmente, fusionamos/rebasemos los otros proyectos de ese repositorio de plantillas, obteniendo las nuevas actualizaciones.

Suena un poco complicado, pero fue solo para la configuración. El flujo de trabajo actual es bastante simple y fácil, con la ventaja dada de trabajar con varios desarrolladores sin problemas mayores.

Answer 2

Estamos haciendo algo similar en mi empresa. Excepto que actualmente involucra múltiples entornos (producción, prueba, desarrollo). Estamos utilizando SVN como nuestro SCM para mantener nuestro código correcto y nos permite duplicar el entorno estable actual y crear versiones separadas de una aplicación (y potencialmente cambiar cosas como los logotipos o ciertas funcionalidades). Recomiendo ejecutar el entorno con Apache/Nginx y Phusion's Passenger. Esto nos permite ejecutar todas estas aplicaciones por separado, en la misma/similar base de código. Y eso es. Tenemos bases de datos, una producción y un desarrollo para mantener nuestros datos en vivo por separado, pero puede conectar fácilmente dos instancias de aplicación al mismo archivo base de esta manera. Funcionó muy bien para nosotros hasta el momento al poder desarrollar, probar y desplegar múltiples aplicaciones web sin derribar el servidor de producción primario.

Answer 3

Con un toque mínimo del sitio principal, es posible que pueda usar el código Ruby mientras extiende las plantillas y cambia los estilos. He trabajado en ese extensamente en Django y el diseño puede verse como:

project/ 
    sites/ 
     site_one/ 
      templates/ 
      models.py 
      settings.py 
      urls.py 
      views.py 
     site_two/ 
      templates/ 
      models.py 
      settings.py 
      urls.py 
      views.py 
    base_app/ 
    settings.py 

Usted podría intentar hacer algo similar en rieles:

main_webapp/ 
    app/ 
    config/ 
    ... 
    sites/ 
     site_one/ 
      controllers/ 
      models/ 
      views/ 
     site_two/ 
      controllers/ 
      models/ 
      views/ 

Suponiendo que las funcionalidades son idénticos a otro, pero sólo tienen diferente diseño y estilos, habrá ninguno o muy poco código de modelo y controlador. Si desea agregar más funcionalidades a sitios específicos, solo inserte el código debajo de la carpeta del sitio deseado.

Django también tiene el concepto de Sites y el ability para buscar plantillas en una carpeta de proyecto específico y una carpeta de aplicación. Podría intentar copiar esas características y llevarlas a Rails para lograr ejecutar múltiples sitios desde una base de código.

Reconozco que está buscando una solución de Rails pero todavía puede comprobar cómo se hace en Django y copiar algunas de las funciones útiles en el otro lado. Si me gusta la función específica de Rails, la transferiré a Django/Python.

Answer 4

Sé que esto podría ser posible utilizando Git Submodules