Los despliegues de aplicaciones web son complejos desde el principio. A menudo se comienza con al menos un despliegue de staging y otro de producción. A esto se suma la multi-tenencia, las configuraciones para integraciones de terceros como la autenticación de Facebook o Salesforce, las configuraciones para el almacenamiento en la nube y las redes de distribución de contenido, los entornos de integración continua, la tematización multi-cliente, las configuraciones de SSL, las configuraciones de vhost, las configuraciones de procesos de construcción para frontends de js, la configuración de tareas en segundo plano, la configuración de procesamiento de cargas, la lista continúa... explosión combinatoria.

En dojo4 tenemos un stack de aplicaciones web basado en rails y usamos Multistage Capistrano para el despliegue en nodos AWS EC2. Hemos encontrado una estrategia simple para gestionar la gran variedad de configuraciones y requisitos de despliegue que nuestros clientes nos han presentado. La estrategia implica una tarea de rake que utiliza una variable de entorno RAILS_STAGE basada en la etapa Multistage de Capistrano. Configuramos una estructura de archivos para configuraciones específicas de despliegue en repo_root/config/deploy/files/RAILS_STAGE que está estructurada de manera idéntica al sistema de archivos del repositorio fuente. Durante el despliegue de cap, antes del enlace simbólico actual o los procesos de construcción, la tarea de rake copia recursivamente repo_root/config/deploy/files/RAILS_STAGE en repo_root.

Hemos encontrado que esta estrategia organiza de manera muy efectiva las configuraciones de despliegue complejas de una manera limpia y fácil de razonar, sin añadir mucha complejidad adicional a una arquitectura ya compleja.

El gist a continuación demuestra esta idea. Originalmente, esta tarea utilizaba varias librerías de rails. Sin embargo, pude eliminar las dependencias de rails mientras mantenía la funcionalidad de la tarea para que puedas usarla con cualquier stack de aplicaciones.