Pipelines de Jenkins: evolución del Continuous Delivery.

Cada vez es más frecuente escuchar la palabra “Pipeline” y, a su vez, es más común ver proyectos que tienen sus pipelines desarrollados con Jenkins.

Hace no mucho, me tocó adentrarme en el mundo de los pipelines de Jenkins y, por este motivo, me he decidido a escribir este post con las conclusiones que he sacado durante este tiempo de aprendizaje.

¿Qué es un delivery pipeline y qué son los pipelines de Jenkins?

Lo primero que debemos hacer es diferenciar entre un delivery pipeline y pipeline de Jenkins, ya que frecuentemente son términos que tienden a confundirse entre sí.

¿Qué es un Delivery pipeline?

Es en esencia, una implementación automatizada de la construcción, testeo, despliegue y el proceso de puesta en producción de la aplicación.

Sus propósitos son:

• Hacer visible cada parte del proceso de construcción, implementación, pruebas y liberación de software a todo el mundo que participa en el proyecto.
• Obtener feedback lo más rápido posible de modo que los problemas sean identificados y resultados tan pronto como se pueda, facilitando su solución.
• Permite a los equipos, dejar a disposición del responsable software compilado y testado, preparado para producción en cualquier momento a través de un proceso totalmente automatizado.

¿Qué son los pipelines de Jenkins?

Son un conjunto de complementos que nos permiten definir nuestros flujos de integración/entrega continua (delivery pipeline) en Jenkins.

¿Cuáles son los elementos principales de un Pipeline de Jenkins?

Lo primero que debemos saber es que los jobs y todo su contenido ya no son definidos mediante la interfaz de Jenkins. Estos son desarrollados en Groovy.

Jenkinsfile

El pipeline del proyecto se declara en un fichero, se almacena y se versiona junto con el código en un fichero comúnmente llamado Jenkinsfile. En este fichero definimos principalmente las fases (stages) de que las consta nuestro flujo.

A parte de las fases mencionadas anteriormente podemos añadir cualquier código que necesitemos como funciones, parámetros, configuraciones...

Stages (Fases)

Las fases de nuestro flujo pueden ser muy distintas según el proyecto y las tecnologías con las que trabajemos.

Por ejemplo, cuando hablamos de fases en un flujo de Continuous Deployment, estamos hablando de cada una de las etapas que tenemos desde que el desarrollador sube su código hasta que este es desplegado automáticamente.

Un proyecto java común puede estar compuesto por fases (stages) como: clonado de código, compilado, ejecución de tests, análisis estático, generación y subida de artefacto,construcción de imagen docker y despliegue.

¿Qué nos aportan realmente?

Mantenibilidad

El Jenkinsfile que compone nuestro flujo se almacena junto al código. Con ello, se vuelve mucho más mantenible, ya que es modificable por cualquier desarrollador que tenga acceso al repositorio.

También ganamos todo el potencial que nos proporcionan Github, Bitbucket o cualquier herramienta similar, como ver el histórico de cambios, versionado del fichero...

La mantenibilidad y versionado es uno de los principales pilares cuando hablamos de Pipelines, pero algunos ya teníamos esto sin necesidad de ellos.

¿Qué ocurre si usamos un job típico de Jenkins, que llame a un script que a su vez ejecute cada uno de los comando necesarios de nuestro flujo? Que si almacenamos este script junto al código tenemos la misma mantenibilidad, control de versionado... que conseguimos con los Jenkinsfile.

En los Jenkinsfiles no sólo almacenamos comandos necesarios. A parte de esto, podemos añadir muchos más elementos como: gestión de credenciales, ficheros, uso de plugins… que antes pertenecían más a la propia configuración del job.

Flexibilidad

Jenkins ofrece gran variedad de plugins que ayudan con las tareas más comunes. Los pipelines son compatibles con la gran mayoría de ellos y nos aportan una gran mejoría.

Al ser programáticos permiten controlar mejor los escenarios y añadir nuevas variantes que eran imposibles hasta ahora.

Esto tiene un punto negativo. Muchas veces es mucho más engorroso definir una una tarea usando un plugin desde un Jenkinsfile, de lo que lo era usando el mismo plugin desde la interfaz de Jenkins.

Visibilidad

Ofrecen una visualización completa de forma atractiva e intuitiva dándonos un feedback rápido del proceso. De un vistazo puede detectarse si hay algún problema y en qué parte de nuestro pipeline ha sucedido.

En ejemplo de ello lo podemos ver en la siguiente imagen. Donde podemos ver rápidamente el resultado y la duración de cada ejecución.

También ganamos gran visibilidad de los resultados a la hora de ver los logs. Podemos acceder a los de cada fase de forma individual sin tener que sumergirnos en los largos logs de salida de la consola. Gracias a esto ahorramos mucho tiempo a la hora localizar un error en la ejecución.

Para acceder a los logs solo hay que situarse sobre el stage del que queramos consultaros y hacer un clic.

La evolución de los Jobs

He pasado por muchos proyectos y por varias empresas. En todas ellas he ido viendo la evolución que han ido sufriendo los jobs de Jenkins. Aunque el fin era el mismo, el cómo desarrollarlos ha ido cambiando bastante.

Tarea de tipo libre con los pasos escritos directamente en el job

Usando tareas de este tipo y escribiendo un comando tras otro, desarrollé mi primera tarea en Jenkins y muchas más que vinieron después. Aunque ha pasado bastante tiempo, sigue siendo muy común hoy en día.

Para ello simplemente tenemos que seleccionar una tarea de tipo libre y añadir los comandos necesarios en un step.

Ventaja:

• Sin necesidad de usar gestores de código.

Desventajas:

• Sin control de versiones.
• Riesgo de pérdida de información.
• No reutilización de código, parámetros, plugins...

Tarea de tipo libre con los pasos escritos en uno o varios scripts

Esta forma de desarrollar nuestros flujos no cambia mucho con respecto a la anterior, aunque nos aporta bastantes ventajas.

Si no se quieren usar pipelines de Jenkins, al menos deberíamos definir nuestros pasos en un script y no directamente en el job.

Ventajas:

• Control de versiones.
• Evitamos el riesgo de pérdida de código.
• Reutilización de código.

Desventajas:

• No evitamos el riesgo de pérdida de configuración.
• No reutilización de parámetros, plugins...

Tarea de tipo pipeline

Ventajas:

• Control de versiones.
• Evitamos el riesgo de pérdida de código y configuración.
• Reutilización de código, parámetros, visualización, plugins...

Desventaja:

• Necesidad de mayores conocimientos técnicos.

Pipeline Syntax, tu mejor amigo

Como ya comenté en anteriormente, muchas veces resulta muy engorroso usar un plugin de forma programática desde el Jenkinsfile. Esto es debido a que es necesario conocer cómo escribir el código necesario de cada uno de los plugins y para sus diferentes usos. Para ayudarnos tenemos la herramienta Pipeline Syntax.

Con esta herramienta seleccionamos el plugin que queremos utilizar y su configuración y obtenemos el código necesario para pegarlo en nuestro fichero.

No es una herramienta muy intuitiva, ya que la interface tiene mucho que mejorar, pero nos ayuda muchísimo a la hora de usar plugins de Jenkins con pipelines.

Muchas veces confiamos en nuevas tecnologías/herramientas porque están de moda, sin saber realmente qué nos aportan y en qué mejoran lo que ya tenemos.

Bajo mi punto, a los pipelines les quedan un largo camino en el que irán apareciendo mejoras que nos ayudarán aún más en nuestro día a día.

A corto o medio plazo deberían ir sacando nuevas versiones y nuevos plugins que nos faciliten el desarrollo de nuestros pipelines. Puede resultar un poco complicado a nivel técnico empezar a trabajar con ellos y eso puede hacer que algunas personas se pierdan las grandes ventajas que nos aportan únicamente por temor.

Si hablamos de Continuous Delivery, me atrevo a decir que los pipelines de Jenkins son el presente y futuro.

“Tenemos un plan estratégico. Se llama hacer las cosas bien”, Herb Kelleher.