Jira y Jenkins: cómo integrarlas correctamente.

Jira es una herramienta de gestión de proyectos e incidencias bastante famosa y que está pensada para ayudar a los equipos a gestionar su trabajo. Jenkins, por otro lado, es un software de integración continua, open source, escrito en Java, que hace de inspector y revisa en detalle que todo esté correcto antes de subirlo a producción.

Ambas son herramientas muy conocidas que nos ofrecen multitud de beneficios y ventajas. Charlamos con Pablo Herrera, QA de Paradigma Digital, que nos cuenta cómo conectarlas correctamente y la mejor manera de configurar estas herramientas para sacarles el máximo partido.

1. Antes de profundizar en la materia, ¿qué es un pipeline de Jenkins y cómo utilizarlo y cómo definirías las “releases” de Jira?

Jenkins es una herramienta que nos permite automatizar procesos. Antes de empezar a desarrollar cualquier pipeline, hay que hacer una definición teórica de cuál va a ser el proceso.

A nivel de desarrollo o del ciclo de vida del software, en un proceso definimos las diferentes etapas por las que va a pasar el producto antes de su publicación. Por ejemplo, si tienes un producto desarrollado en java, antes de nada, lo tienes ubicado en un repositorio, en un gestor de código como gitlab. Las siguientes etapas serán:

• Primero, descargar el código.
• Lo siguiente será la compilación para generar el artefacto. Si tienes algún conjunto de pruebas, unitarias, de integración, end to end, etc. tendrías que ejecutar ese tipo de pruebas.
• Luego, pasarías por la etapa de generar el artefacto final.
• Y, por último, el despliegue.

Una vez definido de forma teórica este proceso, el pipeline consiste en traducir o automatizar ese proceso teórico. Jenkins te ayudará mucho, proporcionando lo que él denomina pipelines (tuberías).

Por otro lado, Jira es un gestor de tareas (pertenece a la empresa Atlassian). ¿Qué es un release? Tú trabajas es un producto que puede ser susceptible de publicarse al final de un sprint, dando una versión y ayudando a hacer un seguimiento sobre el conjunto de tareas que van a ir en esa versión: eso es un release.

Además, Jira te muestra un calendario, con las fechas en las que se van a publicar las releases con sus tareas y funcionalidades.

2. Cuando hablamos de ‘sinergia tecnológica’, ¿a qué nos referimos?

El término ‘sinergia tecnológica’ es una invención mía. En un equipo existen distintas sinergias, se trata de una una cooperación, nos beneficiamos unos de otros de forma cooperativa, de tal forma que el producto final en el que estamos trabajando saldrá como una única unidad, aunque de manera individual hagamos cosas diferentes.

Por ejemplo, en Paradigma trabajamos día a día con esas sinergias: equipos de back, front, PO, QA, Scrum Masters... se apoyan unos a otros para sacar un producto final.

En tecnología diríamos que es lo mismo, eso es la ‘sinergia tecnológica’. Hay un boom de tecnologías increíbles, con nuevas herramientas y nuevas plataformas que, a su vez, generan satélites (herramientas que están ahí y se usan de forma aislada, pero que podrían relacionarse con otras herramientas).

Aunque individualmente hacen cosas diferentes, el objetivo final es el mismo: conseguir sacar un producto. Generar una sinergia tecnológica es ver cómo podrían comunicarse las diferentes herramientas, que actualmente pueden ser satélites y transformarlas como un equipo, trabajando de forma conjunta para un resultado común.

3. En cuanto a la implementación, vamos a empezar hablando de tickets y desarrollos, ¿existe una correlación entre ellos?

Primero tenemos que ver si existe una correlación, si podemos generar una cooperación entre dos herramientas; en este caso, sería entre Jira y Jenkins. Estas herramientas sí tienen una correlación directa.

No en vano, cuando creamos una tarea en Jira, habitualmente, la buena práctica que proponemos es que a un ticket se le asigne una rama; es decir, un sitio donde tú vas a trabajar el código de esa tarea. Un ticket tiene una correlación con un desarrollo funcional.

4. ¿Cuál es la diferencia entre versión de producto (‘bundle version’) y de proyecto?

Digamos que la ‘bundle version’, la versión de producto, es la que se trabaja a nivel de negocio. Por ejemplo, como Product Owner o stakeholder no debo de conocer cuántos proyectos componen mi producto; mientras que nosotros no conocemos cuántos proyectos compone, por ejemplo whatsapp, y cuántas cosas tiene que desplegar para que whatsapp envíe mensajes de forma correcta.

Lo que vemos, en la versión de producto, son las funcionalidades que hemos añadido a ese producto. Pero, lógicamente, todos los proyectos o aplicaciones que se han tenido que desplegar para dar la funcionalidad global son versiones del proyecto.

Siguiendo este ejemplo de whatsapp, tú puedes tener una versión, en la que vas a incluir tres funcionalidades, pero implementar estas tres funcionalidades impacta en seis proyectos y cada proyecto tendrá su versión de desarrollo. Y, de esta forma, tenemos una correlación transparente a través de Jira.

Mirando la versión de mis releases de Jira o mi ‘bundle version’, podremos ver todo lo que conlleva incluir esas tres funcionalidades y a nivel técnico cómo se desglosa en los diferentes tickets.

5. Cuando decides utilizar un código que no es tuyo, por ejemplo una librería, al final tienes que estar al día de las últimas versiones que vayan sacando. Ahí entra en juego la versión semántica. ¿Por qué es importante?

Una versión es un conjunto de patrones que te ayuda a identificar lo que estás haciendo. La versión es solo una nomenclatura que se estipula con el equipo y la sigues. La versión semántica se compone de X, Y y Z (a veces, también se compone de una W si quieres llevar una correlación del número de interacciones que se publican).

Entonces, ¿por qué se escucha tanto esto de versión semántica? La versión semántica lo que aporta es un semi lenguaje y esto ayuda a la automatización. Por ejemplo, si trabajamos con el dígito X para cambios mayores (seguridad o diseño), modificarías el dígito X; luego, el dígito Y sería para cambios menores (se incrementa por cada iteración del sprint); y, por último, el dígito Z que habitualmente se usa para hotfix.

Una vez definido ese semi lenguaje sobre cómo incrementar cada dígito, puedes automatizarlo, hacer que ese incremento de versión y control de versiones y compatibilidades pueda ser automatizable. Las versiones semánticas te podrían permitir automatizar toda la gestión de versiones.

Ahora que está muy de moda todo lo relacionado con los microservicios y la fragmentación de monolitos, cada microservicio va a tener una versión y, en conjunto, volviendo a la ‘bundle version’, vas a tener la versión de tu producto.

Cuando vas a desplegar un producto, tienes que desplegar, por ejemplo, 21 versiones de microservicios, y tienes que asegurarte que todas esas versiones de microservicios son retrocompatibles con ellas.

Con la versión semántica acotas todas esas variaciones y te permite automatizarlas y asegurarte que al publicar la ‘bundle version’ publicas todas las versiones y que esas versiones son retrocompatibles.

6. ¿Cómo implementarlo?

El puglin se llama Jira Pipeline Steps, y nos permite tener esa sinergía tecnológica entre Jira y Jenkins. Este plugin nos proporciona un conjunto de funcionalidades adicionales con las que podemos interactuar directamente con Jira como crear tickets y modificar el estado, adjuntar archivos, poner comentarios… permite, en resumen, lo mismo que la API de Jira.

Lo primero, cuando instalas el plugin de Jira Pipeline en Jenkis, es la configuración: decirle cuál es tu Jira, dónde está ubicado, la url, un usuario y un password (realmente es tu token de Jira). Una vez que se ha configurado, lo que se hace es ir a ese diccionario de steps que te proporciona el plugin para ver los diferentes steps.

Todos funcionan de la misma forma, lanzas una sentencia JQL y te devuelve en formato json el resultado. Por ejemplo, si quieres crear un ticket, tienes que enviar en formato json las características que requieren ese ticket.

7. ¿Qué podríamos hacer con este plugin?, ¿cuál es el potencial?

Uno de los principales beneficios es que podemos eliminar el ‘error humano’. El pipeline de Jenkins es el que se encarga de publicar. Estamos ‘humanizando las herramientas’ haciendo que se comuniquen con nosotros como un miembro más del equipo.

Puede ser a través de los tickets o generando una sinergia con slack, gmail o skype y que Jenkins notifique a esos canales que se ha publicado en el ‘entorno x’ tantos tickets de Jira.

8. ¿Y qué más beneficios podemos encontrar?

Por ejemplo, podríamos hacer la gestión de la retrocompatibilidad no solo a través de helm files sino también creando un fichero yaml con las versiones semánticas de los proyectos.

Esto nos ayuda a poder automatizar, es decir, escribir esa lógica que nos permita incrementar cada dígito. Jenkins es un embudo que gestiona toda la parte técnica y va escribiendo la retrocompatibilidad respecto a las versiones: por ejemplo, este microservicio ha publicado esta nueva versión y, además, le ha desplegado en ‘x’ artefacto.

9. ¿Cuáles serían algunas posibles mejoras?

En relación con los microservicios, un producto no solo se compone de microservicios, sino que se compone de versiones de bases de datos, versiones de la parte de front, de las APIs… y, todo eso, a su vez, compone la versión de un producto. Una posible mejora sería que Jenkins escribiera en el ticket la versión del proyecto, así eliminas la posibilidad del error humano.

En resumen, estamos centralizando la información en Jenkins porque es la tubería por donde pasa todo. Por esto, tiene sentido que se conecten las diferentes tecnologías en Jenkins y que sea Jenkins quien recopile todo.

Esta sinergia no solo sirve para facilitar el trabajo del equipo y para dar seguridad a la calidad del producto, sino para aglutinar o reunir todos los datos en un solo sitio y, si tú quieres, poder explotarlos en un futuro,

Conclusión

Estas son algunas de las principales ideas y puntos fuertes que hemos extraído de la conversación con Pablo sobre la relación y sinergias entre Jira y Jenkins. ¿Quieres escuchar la conversación completa? No te pierdas entonces nuestro podcast Apasionados por la Tecnologías. ¡Escúchalo ya mismo!