Construyendo pipelines en Valencia DevOps

Los pipelines son el día a día para el despliegue continuo, y en el último meetup de Valencia DevOps hicimos unos ejercicios que nos llevaron a conclusiones muy interesantes.

Si me conoces ya sabes que le doy mucha importancia a la formación, sobre todo con aquello relacionado con la cultura DevOps.

Echo la vista atrás y no puedo evitar reflexionar sobre todo lo que he aprendido a lo largo de estos años, cómo ha cambiado el trabajo en el sector tecnológico, y cuánto me ha ayudado mantenerme al día.

Así que, tengo la (muy buena) costumbre de asistir siempre que puedo a eventos y charlas como las organizadas por meetup.com.

Y en este caso, ya he asistido en un par de ocasiones al que realiza el grupo de Valencia DevOps, y os recomiendo que siempre que podáis, vayáis.

Se reúnen una vez al mes entre cervezas para compartir conocimientos y novedades sobre herramientas, flujos de desarrollo y despliegue.

Pues bien, el meetup en esta ocasión, tenía como objetivo construir pipelines por parejas, para después de compartir con el resto del grupo.

Y gracias a esto pude sacar conclusiones que me parecieron muy interesantes.

Pero antes ¿Qué es un pipeline?

En DevOps, un pipeline es el flujo que recorre una aplicación desde (en un caso ideal) la descarga de código del repositorio, hasta el despliegue en el entorno planificado (test, producción…)

La ventaja de utilizar pipelines es obvia, pasamos de que la aplicación vaya de departamento a departamento ( desarrollo, calidad, sistemas, otra vez calidad, etc… ) a que vaya por un flujo planificado previamente, con los beneficios que nos aporta la automatización (velocidad, seguridad, calidad, homogeneidad, etc…)

Pipeline

Actualmente, la herramienta que más utilizo para definir estos pipelines, es Jenkins. Y para definir los pipelines, programo distintos jobs consecutivos para que realicen cada una de las fases: descarga de código, construcción, pruebas, despliegue…

Una vez preparados estos jobs, la forma de enlazarlos puede ser desde el mismo job (indicándole por cuál debe seguir) o bien a través de un archivo .jenkinsfile (que contiene la ruta a seguir)

Soy más partidario de realizarlo de la segunda forma, pues el desarrollador se asegura de las fases por las que va a pasar su código, y de esta forma, no depende tanto que de alguien (de Sistemas-Ops) tenga que preparale la infraestructura… y esto acabe separando (otra vez) Dev y Ops.

Ejercicio de construcción de pipelines

La propuesta del ejercicio era sencilla, pero para nada lo era su solución.

Debíamos pensar en un artefacto que quisiéramos construir y desplegar, y establecer el pipeline que recorrería, para después presentarlo al resto del grupo y compartirlo (y sacarle pegas, claro, que así se aprende mucho 🙂 )

No era necesario utilizar Jenkins, ni CircleCI, ni ninguna herramienta de integración continua, era suficiente con un diagrama flujo, porque lo más importante era ver el recorrido que seguía nuestra aplicación.

Otro de los detalles que me gustó fue que, en la medida de lo posible, nos pusimos por parejas de manera que no conociéramos a la otra persona, lo que ayudaba a compartir experiencias y puntos de vista distintos.

Así que nos pusimos, manos a la obra por parejas, a realizar el ejercicio.

El pipeline que definí junto a mi compañero fue muy simple

DevOps Pipeline

Primero descargaba el código, después compilaba (obteniendo las dependencias de un repositorio) y realizando en el mismo job las pruebas unitarias, a continuación realizaba las pruebas de interfaz, para seguir con la inspección de código, y una vez superado esto, desplegaba en un entorno de desarrollo, preproducción o producción.

Otro detalle que comentamos en nuestra presentación, fue la de no incluir pruebas una vez desplegado en producción. Intento seguir el mantra de: «Cuando llegue a producción tiene que ser perfecto», pero sé que prescindir de esas pruebas es un utopía, y realizar Canary Test puede ser de gran ayuda.

Nota: en el diagrama que presenté, indiqué que el artefacto se debía guardar si compilaba la aplicación, pero en la exposición me di cuenta del error. Mucho mejor guardarlo después de al menos, realizar las pruebas de interfaz, pues sería fácil tener artefactos que en realidad eran inservibles. En el diagrama que he puesto más arriba lo he indicado corregido, para quien no lea completamente el artículo y solo lo «escanee» no cometa el mismo error que yo 🙂

Conclusiones de los pipelines realizados

Sobre el resto de ejercicios, hubo bastante variedad a pesar de los pocos grupos que éramos: desde pipelines sencillos de apenas 3 fases (checkout, build y deployment), hasta pipelines con contenedores que obtenían datos de ejemplo para la base de datos y realizar pruebas más específicas

Así que llegó el momento más importante del meetup, exponer nuestros pipelines al resto de grupos, encontrar defectos y ver cómo los podíamos mejorar.

Y las conclusiones que saqué fueron:

No definimos suficientemente la aplicación

En el planteamiento del ejercicio no se concretó la aplicación que debía recorrer el pipeline, con el objetivo de no concretar o dar pistas sobre cómo debía ser el recorrido.

Sin embargo, en mi opinión, tampoco en ningún grupo definimos muy al detalle la aplicación que estábamos desplegando, lo que hacía que cada uno de nuestros diagramas muchas veces generara más dudas que solucionaba.

Y, por supuesto, los detalles del artefacto eran muy, muy importantes, pues es función de esos detalles, podríamos concretar mejor nuestro pipeline.

Las pruebas eran muy variadas

Donde hubo opiniones más dispares fue en cómo y cuando realizar cada una de las pruebas.

A pesar de que, en la exposición de nuestros pipelines, pudimos acercar posturas sobre cómo y dónde realizar las pruebas, finalmente parece que había más diferencia de opinión o simplemente desconocimiento.

También me pareció destacable que en muchos casos ni siquiera había pruebas unitarias.

Puede que el entorno de preproducción tienda a desaparecer

En algunos casos, tuvimos en cuenta el despliegue en un entorno de preproducción.

Pero en otros no ya que, si los desarrolladores ya tenían sus pruebas en sus respectivos entornos, y hoy en día ya contamos con la posibilidad de automatizar el resto de pruebas, no deberíamos encontrar nada destacable en preproducción.

La realidad, es que en muchos casos siguen existiendo esos entornos de preproducción o stage, y por ello lo tuve en cuenta. Pero sí, hay que pensar sobre ello, y si no es necesario, eliminar desperdicios.

Podríamos incluir la monitorización en el pipeline

Esto se me ocurrió días después.

Y es que algo muy importante en DevOps es monitorizar y obtener datos del despligue. Que recuerde no estuvo presente en ningún pipeline.

Sin embargo, creo que de alguna forma deberíamos tenerlo más en cuenta, y de esta forma, integrar todo el proceso.

Había mucho Dev, pero poco Ops

Algo en lo que no caímos ningún grupo, y para mí la conclusión más destacable, es que nadie pensó en la infraestructura.

Todos pensamos en el desarrollo, descarga de código, pruebas, etc… Sí, en algún caso pensaban en una base de datos, pero todos esperamos al final a desplegar en un entorno… ¿y quién desplegaba ese entorno? Alguien de sistemas separado de desarrollo 🙁

Hubiera sido interesante planificar en el pipeline el despliegue de un sistema donde alojar la aplicación, sin tener que separar el proceso.


Por último, recomendarte una vez más que, si eres de Valencia, y te gusta la filosofía DevOps, acudas a estos meetups, lo que nos sirve de gran ayuda a todos los que queremos construir mejor software y entregarlo antes.

Lectura recomendada

Las herramientas de productividad que deberías probar Las herramientas de productividad nos ayudan a tener todo bajo control y organizarnos. Descubre las que utilizo para mejorar mis resultados.

Deja un comentario