Tikal multijob plugin (Jenkins): Trigger on SCM changes

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:

• Una fase es un conjunto de jobs que se ejecutan en paralelo.
• Las fases se ejecutan secuencialmente entre sí.
• En un projecto multijob podemos definir tantas fases como necesitemos.

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:

• En primer lugar, en paralelo, construimos p1 y p2, necesarios para el resto.
• En segundo lugar, construimos p3 y p4.
• Finalizamos construyendo p5.
• p1, p2, p3 y p4 se construirán sólo si se detectan cambios en su correspondiente SCM.
• p5 se construirá siempre, ya que centraliza la distribución del producto.
• La construcción de la línea de desarrollo del producto se encuentra en las ramas branches del proyecto.

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

• p1/branches/p1-1.4.x
• p2/branches/p2-1.1.x
• p3/branches/p3-1.2.x
• p4/branches/p4-1.5.x
• p5/branches/p5-1.6.x

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:

• En caso de que la propiedad de sistema hudson.scm.multijob.build.always tenga el valor true (se puede definir por medio de un parámetro booleano) el job se construirá siempre.
• Para cada job, un checkbox con el título: Build only if SCM changes [ ]. Si activamos esta opción, el job se construirá sólo cuando el polling informe de que se produjeron cambios desde la última construcción, siempre y cuando, la propiedad anterior tenga por valor false.
• Independientemente de lo anterior se lanzará si no se ha lanzado nunca ninguna construcción del job.

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).

• No se lanza la construcción de p1, porque desde la última construcción no hubo cambios.
• Se lanza la construcción de p2.
• No se lanza la construcción de p3 ni p4, porque desde la última construcción no hubo cambios.
• Se lanza la construcción de p5.

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:

• El programa Jenkins lo podéis encontrar en: http://jenkins-ci.org
• El programa SonarQube lo podéis encontrar en: http://www.sonarqube.org/
• El plugin Tikal Multijob original lo podéis encontrar en: https://github.com/jenkinsci/tikal-multijob-plugin
• La modificación que he realizado está en: https://github.com/rrialq/tikal-multijob-plugin
• Una guía de uso del plugin Tikal Multijob: http://www.tikalk.com/java/forums/create-multijob-jenkins-using-tikal-multijob-plugin

Nota: noticia enviada por Ramón Rial

Comments

[jcarmonaloeches]

¡Gracias por la aportación amigo!

[Ramón Rial]

¡No merezco agradecimiento por cuatro líneas de código mal contadas!

Empecé a desarrollar la modificación por ganas de participación en un proyecto open source, aunque sin muchas esperanzas de que resultase interesante para los desarrolladores originales, pero resultó gratificante cuando mostrarón interés.

Actualmente estoy estudiando la posibilidad de mejorar la integración con el plugin y con otros plugins, como el condicional.