Como vimos en la primera parte, hemos elegido el flujo de trabajo siguiente:
Los paquetes ejecutables obtenidos por el Build de Talend Open Studio (TOS), se almacenan con versionado en un repositorio de Nexus.
Jenkins sacará la versión de producción. Puede ser una versión especifica o la última versión.
El paquete ejecutable Java es un archivo comprimido zip, que se debe extraer al espacio de trabajo de Jenkins. Jenkins, a continuación, lanza uno de los scripts del paquete que son bat, powershell ou shell según la plataforma del agente.
Un ejemplo de script Groovy completo (Jenkins File) se presentará en la tercera parte.
La instalación de Nexus se realiza según el procedimiento detallado en le pagina de Sonatype https://help.sonatype.com/repomanager3/product-information/download
Nexus puede instalarse en cualquier maquina de la red, siempre que se pueda acceder desde el agente y el controlador de Jenkins.
El código del servidor Nexus está en forma de archivo comprimido. El servidor se lanza mediante comando “nexus run/start”. El comando exacto se encuentra en la pagina de https://help.sonatype.com/repomanager3/installation-and-upgrades/installation-methods
Ejecutar Nexus como servicio en el servidor necesita pasos diferente descritos por plataforma https://help.sonatype.com/repomanager3/installation-and-upgrades/run-as-a-service
Se crea un repositorio de tipo Maven / Hosted que es el tipo adecuado para los artefactos de Java tales como un paquete construido por Talend.
En Jenkins, para que la magia actué, hay que realizar esos ajustes:
URL IP y puerto de acceso en la red, evitando localhost
Con esos ajustes básicos, el controlador está preparado para funcionar, pero le falta definir nodos de ejecución. Por defecto ya existe el nodo del controlador (Built-In).
Hay una sección de configuración que permite de agregar nuevos nodos:
En general, lo mejor es instalar el código del agente automáticamente desde el controlador conectándolo por SSH. En cambio, si el nodo es una maquina Windows, se aconseja de instalar manualmente el agente en la maquina y lanzarlo. El controlador genera una línea de comando única que permite al agente Windows de llamar al controlador cuando está activo.
Una vez acabada la configuración, se puede probar un primero proyecto freestyle para cargar nuestro primero artefacto en el repositorio Nexus.
Se crea un nuevo elemento de tipo “Freestyle Project”
Se añade un paso de publicación a Nexus 3:
Puesto que hemos configurado el servidor se nos aparece en el menú:
Se escoge en el segundo menú el repositorio donde se quiere subir el artefacto
ponemos los identificadores del paquete et del artefato que tenemos que subir
Guardar y ejecutar (Build en el idioma de Jenkins).
Jenkins nos indica que el build (la subida del artefacto, en nuestro caso) se ha ejecutado con éxito. Y podemos navegar en Nexus para ver el artefacto que acabamos de subir.
De la misma manera podríamos componer un proyecto para automatizar las etapas para seleccionar un artefacto de Nexus, descomprimir el archivo y ejecutar el script lanzador de Java. Como ya vimos, hacer un seguimiento de etapas múltiples vistas como un solo bloque, no es lo más cómodo. Sobre todo que Jenkins dispone de una modalidad que nos permite de ver el resultado de cada etapa por separado.
En la siguiente parte, veremos que los proyectos de tipo pipeline son la herramienta ideal para un seguimiento fino de ejecuciones de pasos múltiples.
