Tikal multijob plugin (Jenkins): Trigger on SCM changes
miƩrcoles, agosto 20, 2014 at 4:13PM
javaHispano

Comenzaré diciendo que Jenkins (http://jenkins-ci.org) es una aplicación que, para quienes nos encontramos involucrados de uno u otro modo en el desarrollo de proyectos no necesita presentación. Su utilidad radica en su concepción como una herramienta de centralización de gestión de la construcción de los proyectos de software.

Uno de sus plugins, Tikal multijob plugin, es posible que sí necesite algo de atención, pero me limitaré a describir su utilidad, no su uso.

Este plugin permite que un job en Jenkins lance la construcción de múltiples jobs, tanto en paralelo como secuencialmente. Para ello se introduce la noción de fase, que presenta las siguientes características:

 

A este plugin le he añadido la funcionalidad necesaria para que se lance la construcción de los jobs definidos en las fases:

  1. Siempre, que es el comportamiento estándar del plugin.
  2. Cuando haya cambios respecto de la última construcción.
  3. En función del valor de una propiedad de sistema (si se suministra)

 

Casi siempre solventamos parcialmente el problema de la construcción por medio de otros plugins, por medio de upstreams y downstreams, con el añadido de scripts, crons y demás opciones que nos proporciona Jenkins.
A mí me parece muy cómodo y funcional el Tikal multijob plugin:
representar la secuencia jerarquizada de construcción en un job en lugar de encadenar varios jobs entre sí por medio de los downstream y upstream.

Esto permite articular, por ejemplo, la construcción de un producto compuesto por múltiples proyectos, de modo que sea posible lanzar en paralelo la construcción de varios de ellos agrupados en una fase, y a su término, lanzar la siguiente fase. Nos ofrece un mecanismo de definir de forma integrada y visualizar gráficamente la secuencia de construcción en sí misma, sin depender de upstreams o downstreams.

En el caso de la integración continua, donde periódicamente se realizan construcciones del código nos encontramos con que a medida que el número de jobs definidos crece, las operaciones de comprobación de cambios en el SCM (polling) son más numerosas, y teniendo en cuenta que estas operaciones son relativamente lentas, configurar los jobs para que Jenkins, cada cierto tiempo, compruebe si hay cambios en el SCM puede no ser viable, o peor aún, quizá sea preciso que se lancen los jobs de una secuencia de construcción en un orden determinado, si es posible en paralelo y si ho hubo cambios que no lance el job en cuestión.

Supongamos un producto de software llamado PRODUCTO dividido en cinco proyectos: p1, p2, p3, p4 y p5.
La construcción sigue el siguiente procedimiento:

 

 

El equipo de mantenimiento se encuentra desarrollando la línea 1.6 de PRODUCTO, según la siguientes ramas de los proyectos:

 

Cada cierto tiempo el equipo de trabajo integra el código en las ramas correspondientes a la línea de desarrollo de los proyectos en los que trabajan tras realizar todas las tareas previas pertinentes, asegurándose incluso, de que su código no rompe la construcción. Aún así se hace necesario comprobar si las piezas encajan tan bien como en los entornos de desarrollo de los miembros del equipo.

Pero en cada integración se modifican algunos proyectos, no todos, por lo que lanzar siempre la construcción de los mismos es un desperdicio de recursos y tiempo en el servidor.
Ahí es donde mi modificación (que según me han comentado los desarrolladores del plugin se integrará con la siguiente versión) puede echar una mano.

Respecto del plugin original, la modificación añade dos características:

 

Los beneficios se ven cuando se poseen muchos jobs definidos en el Jenkins, y se trabaja en la corrección de uno o dos proyectos.
En la primera construcción del multijob, se lanza la construcción de todos los proyectos (suponiendo que nunca se hubiese lanzado la construcción de ninguno de ellos).
Al cabo de un par de horas, alguien integra modificaciones en el branch p2-1.1.x. Jenkins lanza automáticamente el multijob (o alguien de forma manual).

 

Hemos ahorrado los tiempos de espera derivados de la construcción de p1, p3 y p4.

Este tipo de estrategias tiene un único inconveniente: Si se corrige un bug en p1, y esta corrección obliga a comprobar de nuevo en p2, la modificación actual no contempla esta casuística. Se solventa, realizando un commit sobre p2, para actualizar el estado del SCM, que el plugin detecte cambios y que lance la construcción.

Espero que os sea de ayuda, en mi trabajo ayudó a reducir enormemente los tiempos de construcción y simplificar la gestión de la programación de los mismos. Teniendo en cuenta que por la noche se realizan los análisis de calidad con el SonarQube, la reducción de tiempos de construcción fue notable. Ahora poseemos más ventanas temporales para realizar más construcciones sobre el mismo hardware.

Referencias:

Nota: noticia enviada por Ramón Rial

 

Article originally appeared on javaHispano (http://www.javahispano.org/).
See website for complete article licensing information.