Funcionalidades de GeneXus que conviene conocer: Deployment Unit
En GeneXus 16, se pueden definir objetos de tipo Deployment Units. Es una forma de definir un conjunto de objetos que van a ser empaquetados y luego instalados juntos.
Por ejemplo, en una KB por un lado se instalan todos los Webforms y por otro todos los servicios y procesos batch, pues van en otro servidor o en otro directorio.
En cada Deployment Unit se agregan todos los objetos main que quiero distribuir juntos, por ejemplo, si pongo servicios y proceso batch que quiero distribuir podria poner.
Para mi opinion, seria mucho mas claro que esta opción se llamara Packagin Application, en vez de Deploy Application, pues deja mas claro que es lo que realmente se hace, que es crear un paquete con too lo que se va a usar después para hacer un deploy.
Por ejemplo, en una KB por un lado se instalan todos los Webforms y por otro todos los servicios y procesos batch, pues van en otro servidor o en otro directorio.
En cada Deployment Unit se agregan todos los objetos main que quiero distribuir juntos, por ejemplo, si pongo servicios y proceso batch que quiero distribuir podria poner.
Tiene una lista de los procesos batch que quiero enviar a un directorio.
Se listan sólo los main y GeneXus calcula todo los objetos referenciados por esto y lleva todo lo necesario para que ejecute en forma correcta. .
Como se usan?
Después se hace Build / Deploy Application y se elige que Deployment Unit se quiere desplegar y se genera un zip con todo lo necesario para instalar, con los archivos de configuración, con clave de encriptación,etc.Para mi opinion, seria mucho mas claro que esta opción se llamara Packagin Application, en vez de Deploy Application, pues deja mas claro que es lo que realmente se hace, que es crear un paquete con too lo que se va a usar después para hacer un deploy.
El output de una ejecucion del empaquetado:
========== Deploy Application started ==========
Creating deploy project
Creating package
Analyzing files
Copying config files
Copying static files
Copying Themes
Copying static files
Copying QueryViewer resources
Copying resources
Generating IIS version specific web.config
Copying REST cache support
Copying standard files
Copying GAM support files
Copying GAM Backend
Copying Office document support
Copying command line support
Copying UserControls
Copying external files
Copying location.xml
Applying secured keys
Application successfully packaged at 'D:\Models\gx16\MT_v2020_04\
Creating deploy project
Creating package
Analyzing files
Copying config files
Copying static files
Copying Themes
Copying static files
Copying QueryViewer resources
Copying resources
Generating IIS version specific web.config
Copying REST cache support
Copying standard files
Copying GAM support files
Copying GAM Backend
Copying Office document support
Copying command line support
Copying UserControls
Copying external files
Copying location.xml
Applying secured keys
Application successfully packaged at 'D:\Models\gx16\MT_v2020_04\
El deploy puede hacerse local (como en el caso de arriba) o a un contenedor Docker, a la infraestructura de Amazon AWS Elastic Beanstalk, Azure de Microsoft. Para java hay otras opciones adicionales.
Este proceso puede automatizarse y hacerse directamente en el proceso de build y deploy.
Donde podríamos usar esto?.
Para instalar solo lo que queremos. Si nos queremos asegurar de instalar solo los main que nos interesan y no algunos que hicimos para pruebas, es una buena opción tener definidas las deployment units.
En KB donde tenemos mas de un directorio de instalación, son útiles usar las Deployment Units.
Tambien son muy buenas para automatizar el calculo de las referencias de lo que tenemos que instalar y no olvidarnos de llevar algún archivo, por ejemplo, cuando se empieza a usar un nuevo User Control.
Tambien es bueno para no llevar objetos y clases que ya se borraron de la KB, pero siguen estando en el directorio de la misma, que muchas veces se terminan instalando por error, cuando se usan procesos manuales de instalación.
Son fáciles de definir y de mantener y si bien dan un poco de trabajo al principio para su uso, es muy recomendable su utilización en nuevos desarrollo.
La instalacion de aplicaciones es una tarea cada vez mas sofisiticada, donde hay que tener en cuenta aspectos de la plataforma, seguridad, performance, etc y los Deployment Unit hacen dicha tarea un poco mas facil y minimizan la realizacion de errores.
Documentación:
https://wiki.genexus.com/
https://wiki.genexus.com/
https://wiki.genexus.com/commwiki/servlet/wiki?42073,Application+Deployment+MSBuild+tasks
Enrique, probaste hacer deploy a AWS Serverless? Es muy interesante por lo que promete, pero que no logré que funcione con Gx16 U11
ResponderBorrarNo, yo no probe.
BorrarQue problema tuviste?
el error que sale es el siguiente:
Borrarerror: Source file not found: C:\Models\PruebaLambda\Java\Deploy\AWSSERVERLESS\DeploymentUnit1\20201216150656\deploy.api.yaml
Failed: Deploy Application
En esa carpeta se genera el archivo default.yaml y no deploy.api.yaml
Debe ser un error de Genexus porque, con el Gx16 U4 funciona bien y en el U11 ya no.
Pensando en esto:
ResponderBorrarTambien es bueno para no llevar objetos y clases que ya se borraron de la KB, pero siguen estando en el directorio de la misma, que muchas veces se terminan instalando por error, cuando se usan procesos manuales de instalación.
Existe alguna forma de eliminar los .class .js etc de esos objetos que fueron eliminados de la kb y continúan en Tomcat?
Debo tener decenas.
Lo que yo hago, es borrar el directorio del environment y hago un REBUILD ALL.
BorrarCon eso, te aseguras que solo queden los objetos que existen en la KB.
BorrarVoy a probar, pero le desconfío a Gx que se olvide de algúnos lib, css, etc. :/
Gracias Enrique.!!!