Build / Pack / Deploy - Definiendo conceptos.

El esquema general de desarrollo e instalación de aplicaciones desarrolladas con GeneXus es así: 

Las treas que tenemos son:

Build. 

Partiendo de una KB actualizada/modificada se especifican, generan, compilan todos los ejecutables de la aplicación.
Se hace la reorganización de la base de datos necesaria y se salva dicha reorganización. Esta reorganización seria bueno poder ejecutarla solo con un script en forma automática.

Estaria bueno tener un archivo build.info cuyo contenido fuera el identificador de version del ultimo build exitoso y que ademas tenga

GXVer: 16.U9.141222

KBVer: 20200610165879

BuildStart: 2020-06-10t17:01:45

BuildEnd:  2020-06-10t18:45:26

En caso que estemos en un ambiente de CI/CD, si el GXVer del build.info existenten del build anterior y son diferentes, se puede lanzar automáticamente un rebuild all, en vez de un build all. 

El archivo build.info, se  puede renombrar o borrar al empezar la tarea, de forma que las tareas siguientes sepan que esta ejecutando. 

Pack

Esta etapa esta mal modelada hoy en Genexus, pues se mezcla con Deploy.
Lo que hace esta etapa es leer todos los objetos Deployment Units que se tengan en la KB y se genera un zip para cada uno de ellos.
En esta etapa se calculan todas las dependencias y se llevan todas los binarios y todo lo necesario para ejecutar una aplicación, menos los archivos de configuracion y personalizacion.
En esta etapa, solamente se dividen los ejecutables en los grupos que van a ser instalados en diferentes webapps/directorios virtuales o directorios físicos.
El resultado, no es algo pronto para instalar, sino un conjunto de zips (un zip por Deployment Unit). Además se van a tener todas las reorganizaciones que se necesitan desde la última vez que se ejecutó el pack.

Se tendrán también todos los objetos modificados y la lista de los commits que se instalan desde la ultima vez que se hizo el pack.

Seria bueno poder identificar este pack con el identificador del build de la etapa anterior y guardarlo en un archivo pack.info.

GXVer: 16.U9.141222

KBVer: 20200610165879

BuildStart: 2020-06-10t17:01:45

BuildEnd:  2020-06-10t18:45:26

PackStart:  2020-06-10t:20:00:05

PackEnd:   2020-06-10t:20:12:35

El pack no se puede ejecutar, si hay un build ejecutando o si no hay un build exitoso chequeando que exista siempre un build.info antes de hacer un pack. 

El archivo pack.info debe borrarse o renombrarse cuando esta ejecutando el pack para evitar que se ejecute un deploy, con un pack en ejecución. 

Deploy.

  Esta etapa tiene 2 sub-etapas.

Ajustar configuración

Es donde se genera el web.config, client.cfg, etc basado en la información que se tiene del repositorio de ambientes de producción (esto no existe en GeneXus) y para cada una de la webapps que tengan que instalar. 

En esta etapa se personalizan los string de conexión a la base de datos, niveles de log y su configuración, seguridad, certificados. 

Debe tener en cuenta cual es el destino de dicha instalación, pues puede necesitarse diferentes configuración para diferentes herramientas (Azure, Jboss, IIS, tomcat, etc). 

Lo generado en la etapa de pack + archivos de configuración, son los archivos que efectivamente hay que instalar y el resultado puede ser un war, jar o un zip.

Opcionalmente esta tarea va a copiar el contenido de los artefactos generados a un servidor GIT o copiarlo a carpetas accesibles desde produccion, para su posterior instalación. 

Tambien se puede guardar un archivo deploy.info que tenga el identificador cuando fueron realizadas las etapas previas. 

GXVer: 16.U9.141222

KBVer: 20200610165879

BuildStart: 2020-06-10t17:01:45

BuildEnd:  2020-06-10t18:45:26

PackStart:  2020-06-10t:20:00:05

PackEnd:   2020-06-10t:20:12:35

AdaptConfig: 2020-06-10t20:15:00

AdaptConfig: 2020-06-10t20:23:58

No se puede ejecutar un deploy, si no existe un pack exitoso, por lo que hay que chequear que exista siempre el pack.info. 

Deploy efectivo

En esta etapa se instala lo generado en la etapa anterior, en los servidores físicos. 

Se deben crear todos los directorios virtuales / webapps, para cada uno de los servidores donde hay que instalar esto. 

Se deben ejecutar las reorganizaciones necesarias en forma automática. 

Cuando estamos trabajando desde el IDE, todas estas etapas pueden hacerse en un solo paso (como hoy). 

Cuando tenemos que hacer en un ambiente de CI/CD , estas etapas pueden orquestarse con una frecuencia diferente para cada uno de los ambientes. 

Por ejemplo, se puede hacer un build/pack/deploy cada 15 minutos para el ambiente de testeo manual, cada 12 horas para el ambiente de testeo automatizado y semanal para producción. 

Cosas necesarias.

Para poder tener este esquema de build/pack/deploy, necesitamos desarrollar varias cosas:

1. Numero de version (de build all)  autoincrementable (o por timestamp de modificación de la KB. )
2. Grabar archivos de build.info, pack.info y build.info. Estos archivos son útiles para saber que reorgs hay que correr, si no hay nada nuevo para hacer, etc.
3. Salvar reorg en forma automática
4. Poder listar los objetos cambiados y lista de commits.
5. Repositorio de Ambientes de Producción
6. Creación de Directorio Virtual / WebApp
7. Mecanismo para personalización de archivos de configuración. que sea documentado y personalizable. 
8. Dada una instalación existente (con su deploy.info) y una nueva version a instalar (con su nuevo deploy.info) poder ejecutar automáticamente todas las reorgs que existan entre ambas instalaciones. 
9. Separar la etapa de pack de la deploy. El pack lo vamos a hacer casi siempre en el ambiente de desarrollo, el deploy lo vamos a hacer mayoritariamente en los ambientes de ejecución. 

Ya hay varias a medio hacer, pero estaria bueno darle un empujón para poder hacer esta tarea, que cada vez es mas compleja en forma mas automatica. 

Cuando nos enfrentamos a un futuro con containers, microservicios e instalaciones muy frecuentes, este tipo de tareas va a insumir cada vez mas tiempo.