Environments dentro de la KB GeneXus
Un escenario común en aplicaciones Genexus en clientes grandes (y chicos) es el siguiente:
Desde la KB, programo y genero los instalables (pueden ser imágenes docker, war/jar, zip, etc) con los ejecutables y todos lo necesario para ejecutar. Esto tambien tiene los archivos de configuración necesarios para ejecutar con los valores que tengo en la KB o algunos que saco de las propiedades de la KB (web.config, client.cfg, appconfig.json y varios mas).
Luego que hago una instalación en un ambiente de TEST, cuando el responsable lo aprueba (luego de correr test automático, test manuales, o que se cumplan los criterios de aprobación definidos, se pasa al ambiente de pre-produccion, que es mas parecido al ambiente de producción (en algunas instalaciones no existe el ambiente de PRE-Produccion y pasan directo a PRODUCCION).
En este pasaje, los instalables que se instalan SON EXACTAMENTE LOS MISMOS, pero se cambian los archivos de configuración y las variables de ambiente del sistema operativo o del servidor web, para ejecutar en el nuevo ambiente.
Cosas que se cambian de un ambiente a otro:
* Log (nivel y lugar donde se almacenan, cuanto tiempo se guardan, etc)
* Base de Datos (servidor, nombre, y credenciales de conexión)
* Storage Provider (Servidor y credenciales de donde almacenar imágenes, archivos, etc)
* Servicios externos (en caso de consumir servicios externos, a donde deben apuntar, location, baseurl)
Como modelar esto con GeneXus
Al día de hoy, dentro de una KB Genexus puedo tener varios Ambientes (Environments) que permiten manejar la forma en que se genera y se instala una aplicación.
Desde el punto de práctico, la forma en que los ambientes están modelados, producen algunos inconvenientes y tienen oportunidades de mejora, para poder soportar el escenario planteado arriba.
En el entendido que ningún modelo es correcto, sino que algunos son mas útiles que otros, quiero plantear mi punto de vista, para ver si no se puede cambiar algo para hacer mas fácil el manejo e instalación de aplicaciones Genexus.
Diferentes tipos de ambientes.
En el tipo de aplicaciones que desarrollamos, hay diferentes tipos de ambientes.
Ambientes de BUILD
Ambientes de DEPLOY (o DEPLOY TARGET)
En estos ambientes, se fijan todas las propiedades que afectan al deploy de al aplicación, como pueden ser las credenciales de conexión a la base de datos y servicios, tipo y nivel del log, manejo de sesiones, location de servicios consumidos, certificados necesarios, etc
En este ambiente no se modificaran los fuentes de la aplicación, sino solo los archivos de configuración y variables de ambiente necesarias para personalizar el deploy de la aplicación. Por lo tanto, no se necesitará hacer un BUILD all de la aplicación que demora muchisimo. Tampoco se realizara el impacto en la base de datos, pues el mismo ya fue realizado en el ambiente de build y solamente debemos llevar todos los scripts para reorganizar la base de datos, desde el ambiente de BUILD.
Por cada ambiente de BUILD, pueden existir varios ambientes de DEPLOY (o DEPLOY TARGETS)
Por ejemplo:
Tenemos una aplicación de Stock. Es necesario desarrollarlo para un ambiente de .NET Core para un cliente y en Java para otro.
Sistema de Stock
- Ambiente de BUILD - .NET Core / SQL Server
- Ambiente de TEST - Todas las propiedades de DEPLOY a TEST
- Ambiente de PREPRODUCCION
- Ambiente de PRODUCCION
- Ambiente de BUILD - Java / SQL Server
- Ambiente de TEST
- Ambiente de PRODUCCION
De esta forma, podríamos desarrollar la aplicación de Stock, en el ambiente de build, que se encargaría de hacer el build all de la aplicación. Si la misma no tiene errores, ser debería realizar el PACKAGE ALL de la aplicación, ejecutando todas las Deployment Units y generando las imágenes/war/jar/zip que sean necesarios y se almacenarían con un identificador de una numero de versión del empaquetado.
Una vez que el empaquetado esta terminado, se puede pasar a los diferentes ambientes de deploy, a través de comandos que permitan la personalización de los archivos de configuración, las variables de ambientes necesarios para la ejecución, la configuración de los servicios a consumir, etc.
El tener los ambientes diferenciados en ambientes de build y de deploy, facilitarían mucho el manejo que hoy hacemos y dejaria mas claro que son las personalizaciones necesarias para un deploy exitoso y con menores riesgos.
Que se necesita cambiar en GeneXus?
Jerarquía de ambientes/deploy targets
Tener una jerarquía de ambientes, o diferenciar entre environment y deploy targets, para solo permitir modificar las propiedades en los lugares correctos. En un deploy target, no se debería poder modificar ninguna propiedad que afecte a la generación del código.Versionado en la aplicación
Para hacer mas fácil el seguimiento y gestión de la instalacion en diferentes ambientes, seria bueno contar con que Genexus actualice un numero de versión cada vez que se termina un build all exitoso o cada vez que se hace un Package All (hace el package de todas las DU de la KB)
Utilitarios para generar los scripts que pasan de un ambiente a otro.
Para pasar de TEST a PRODUCCION, debo tener un conjunto de script que permitan hacer ese pasaje en forma segura.
- Tenemos que poder setear las variables de entorno los valores de PRODUCCION
- Ejecutar los scripts de reorg de la base de datos (si existiera)
- Impactar los cambios de metadata de GAM
- Impactar los cambios de la metadata de GXFlow
- Impactar los cambios de la metadata de la aplicación (por ejemplo location / server / baseurl de servicios)
- Adaptar los archivos de configuración que no puedan manejarse con variables de entorno
- Scripts de instalación que hagan un backup de la instalación anterior e instalen la nueva versión
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.