Llega un momento en cualquier proyecto de Denodo en el que «exporto el VQL de desarrollo y lo importo a mano en producción» deja de ser sostenible: crece el número de vistas, crece el equipo, y con ello el riesgo de promocionar el cambio equivocado o de perder el rastro de quién movió qué. Denodo Solution Manager existe justo para poner orden en ese proceso de despliegue entre entornos.
Entornos, servidores y revisiones
Solution Manager organiza el ciclo de vida de un proyecto Denodo alrededor de tres ideas. Un entorno (desarrollo, preproducción, producción…) agrupa uno o varios servidores de Denodo que juegan ese mismo papel. Una revisión es el paquete de cambios que se quiere mover de un entorno a otro: puede incluir vistas nuevas, modificaciones de vistas existentes, cambios de privilegios o prácticamente cualquier elemento de metadatos de VDP. Y un despliegue es la operación concreta de aplicar una o varias revisiones sobre los servidores de un entorno destino.
La ventaja frente al método manual no es solo comodidad: Solution Manager deja constancia de qué revisión se desplegó, cuándo, sobre qué entorno y con qué resultado, algo que un simple export/import de VQL nunca ofrece por sí solo.
El flujo de promoción recomendado
La propia documentación de buenas prácticas de Denodo describe un flujo de trabajo bastante concreto para mover cambios entre entornos:
El desarrollador hace sus cambios sobre el entorno de desarrollo y los deja registrados en el sistema de control de versiones del equipo.
Un responsable técnico crea la revisión (o revisiones) que agrupa esos cambios ya consolidados, con un nombre y una descripción que dejen claro qué contiene.
Un administrador revisa la configuración del entorno destino: propiedades específicas de esa instalación que no deben sobrescribirse sin más.
Una persona autorizada ejecuta el despliegue hacia el siguiente entorno y, después, se valida tanto el resultado de la promoción como que la copia de seguridad previa se realizó correctamente.
Cuánto se promociona de una vez
Un punto en el que merece la pena pensar antes de empezar es la granularidad de las revisiones. Denodo describe tres enfoques: promocionar absolutamente todo (razonable en un despliegue inicial o en una refactorización grande), promocionar bases de datos completas, o promocionar únicamente los elementos que realmente cambiaron, que es el enfoque recomendado para el mantenimiento del día a día. Cuanto más granular es una revisión, más fácil resulta después reconstruir el historial de por qué cambió un objeto concreto.
Sobre los privilegios: cuando una revisión incluye cambios de permisos, conviene incluir en ella también los usuarios y roles afectados. Si los entornos no comparten exactamente los mismos usuarios, la recomendación oficial es construir esa parte de la revisión con sentencias VQL explícitas (GRANT) en lugar de crearla gráficamente, para evitar arrastrar diferencias de un entorno a otro sin darse cuenta.
Producción no se despliega como desarrollo
| Entorno | Estrategia de despliegue recomendada |
|---|---|
| Desarrollo / Test | Despliegue simple, sin más complicación: el objetivo es iterar rápido. |
| Producción | Estrategias pensadas para no interrumpir el servicio, coordinadas con el balanceador de carga cuando hay varios servidores. |
También conviene coordinar el despliegue con lo que ya esté planificado en Scheduler: en lugar de forzar la ejecución automática de jobs de caché justo durante la promoción —lo que puede alargar el despliegue innecesariamente—, suele funcionar mejor dejar que la recarga ocurra en su ventana habitual poco después de que la revisión quede aplicada.
Antes de tu próxima promoción
- Nombra y describe cada revisión pensando en quien la lea dentro de seis meses, no en quien la crea hoy.
- Prefiere revisiones granulares por cambio real frente a promocionar bases de datos completas, salvo en despliegues iniciales.
- Si mueves privilegios entre entornos con usuarios distintos, escribe el
GRANTa mano en la revisión en vez de generarlo gráficamente. - No acoples la recarga de caché al momento exacto del despliegue si ya tienes esa carga planificada en Scheduler.
- Verifica siempre el resultado de la promoción y la copia de seguridad antes de dar el despliegue por cerrado.
Solution Manager no elimina la necesidad de disciplina en el equipo —eso lo sigue poniendo el control de versiones y el criterio de quién aprueba cada revisión—, pero sí da un marco común para que promocionar a producción deje de depender de la memoria de una sola persona.
Antes de promocionar cualquier cambio conviene saber si la consulta que vas a mover ya rinde como debería en origen.
Ver cómo diagnosticar consultas en Denodo