Te va a interesar!

6/recent/ticker-posts

Jenkins, Blue Ocean y explosiones.

Photo by Franck V. on Unsplash
¿Cómo dicen que les va? ¿Bien? ¿Aprendiendo cosillas nuevas y manteniéndose activos en el cambiante mundo del Testing y el desarrollo de software? ¡Bien! Esa es la actitud correcta. Yo por mi parte estuve divirtiéndome como hacía tiempo no me divertía haciendo un Chatbot con Python y Machine Learning. La idea es que el Bot se parezca cada vez más a mi en la asociación de palabras que usa para responder. Los resultados tempranos son, mínimo, MUY graciosos. Con decir que mi esposa estuvo hablando con mi Yo Digital por un largo rato y riéndose bastante...

Pero hoy no vengo a hablarles del mindset del buen tester y cómo éste tiene que mantener la pasión, curiosidad y voluntad de aprender deliberadamente para crecer en este competitivo rubro. No, hoy les vengo a hablar sobre Jenkins y cómo, con unos pequeños cambios y unas presentaciones bien marketineras, cambié el rostro de esta simpática herramienta y la orquestación de todo lo que hacemos tanto en Automation como en Desarrollo.  Empiezo contándoles el requerimiento que me cayó, uno de esos bien estrambóticos que me suelen traer porque saben que le pongo inventiva a todo.

Los equipos de desarrollo parchean semanalmente y necesitamos testear el impacto. 

Bueno, bien. Primero que nada, decirles que trabajo para un cliente muy, MUY grande e importante en el país de los All Blacks. No lo digo de canchero, sino porque les quiero decir un par de cosas con esto:

  • No es una aplicación pequeña ni mediana para la que organizo el testing. 
  • La infraestructura detrás es una selva de Proxies, Directorios, Firewalls, whitelists y vaya a saber qué otros seres mitológicos más. Si me decís que hay un puma vigilando los puertos de conexión te creo. Esto significa que el impacto de un parche no es tan sencillo de identificar como esperaría cualquier mortal.
  • La rotación de equipos, sumado a, muchas veces, la falta de conocimientos apropiados para la tarea, hicieron que los muchos proyectos de Automation fuesen demasiado heterogéneos, sin seguir ningún tipo de lineamiento y usando la herramienta equivocada para la tarea equivocada. 
Bueno, el comienzo se veía prometedor. Posta, no lo digo en chiste. Me encanta tener la libertad en una organización para cambiar las cosas en la dirección correcta y resolver nuevos problemas. Así que ahí estaba, hablando de explosiones (si, el jefote confiaba tanto en los desarrolladores que llamaba así a esta tarea, porque era testear la "onda expansiva" del deploy) y pensando el primer paso para lograr esa utopía DevOpsiana a la que aspiraban. 

Primer paso: Hacer inventario de todo lo que tenemos, ande o no. 

Lo primero fue una pieza esencial de trabajo en la que, usando las APIs de Confluence y Jenkins, creamos una página en la que se actualizaba semana a semana, por dominio de cada uno de los componentes de la empresa, todos los artefactos de testing que había en Jenkins. Por suerte, los artefactos en Jenkins seguían una convención para los nombres, dominios y ambientes que pudimos usar a nuestro favor para crear esta página en Confluence.

Esto fue pivotal, ya que la otra manera era empezar a ver Jenkins y armar un Excel o similar, anotando uno por uno los jobs y rezando a la Pachamama por no errar en nada. Con las APIs, no solo nos ahorramos ese garrón, sino que el error humano no estaba entre las posibilidades. Quizás dedique otro post a los desafíos de trabajar con las APIs de Confluence y Jenkins en ambientes bastante herméticos de trabajo.

Genial, ahora teníamos todo ahí, organizado y listo para pensar en el próximo paso, el cual fue...

Identificar la onda expansiva de cada deploy!

Asociar cada patch y deploy con los componentes afectados y, de esta manera, con los tests asociados a estos era el siguiente desafío. Acá no hubo API que me salve y tuve que recurrir a la vieja y, muchas veces no valorada, comunicación humana. Me hizo pensar en cómo DevOps no es simplemente un set de herramientas y procesos, sino también una cultura de comunicación. Así me fui enterando de cosas que no eran aparentes, como les comentaba más arriba, relacionado con la infraestructura y el networking de la empresa. Así que poco a poco fui generando estas "ondas expansivas" y consiguiendo la luz verde de los responsables de los deploys y los módulos afectados. 

Me pareció importante estar todos en la misma página sobre qué se iba a incluir como parte del testing de los parches para evitar que vuelen culpas en caso de que algo no fuese cubierto y reventase. 

Ahora si, el último paso: Crear los tests para las ondas expansivas!


Para esto usé Jenkins. Tenía mi página de Confluence con los artefactos de test para cada módulo, cada cosa linkeada a su respectivo Job en Jenkins con sus reportes. Lo primero que noté era que, muchas veces, los jobs pertenecían a repositorios que nadie había mantenido en lustros. Así que de ahí se desprendió la tarea de actualizar esos repositorios. ¿Y qué mejor que esta oportunidad para alinear todo lo viejo con mis nuevos templates para UI y API? ¿No les conté sobre ésto? ¡Prometo hacer un post en breve contándoles por qué es buena idea implementarlos en sus trabajos!

Una vez estos jobs fueron actualizados, empecé a crear pipelines de Jenkins, pero con un pequeño cambio que nadie usaba todavía en este lugar y me sorprendió: Crear stages para el Smoke Test y que la regresión dependa del éxito del Smoke.

Qué pasaba antes...Jenkins estaba muy ocupado, corriendo miles de Scenarios, cientos de Jobs todos los días. Muchas veces, si algo muy sencillo fallaba, la gente se quedaba esperando a que falle todo o, en el mejor caso si alguien veía que había fallado eso, abortaba la ejecución de la build.

"Yo no te puedo creer" fue lo primero que pensé. Imagínate que la página está directamente caída porque no configuraron bien el ambiente. Jenkins corre 600 Tests, todos fallando porque la página no está levantada. Con todo el tiempo, recursos en los agentes y zaraza que esto implica. Un bajón. Así que agarré y dije "¿Qué tal si tenemos un stage con todo lo que consideremos Smoke tests, ósea...lo mínimo y primordial para dar luz verde a la regresión y, en caso que falle el Smoke, falla todo y ni se ejecuta el resto porque, de todas maneras, iba a fallar?".

Hubo un resonante acuerdo en que si, era mucho mejor así. Así que así fue: Empecé a crear las pipelines que, básicamente, tenían como condicional el Smoke al comienzo y, si salía todo bien, ejecutaba la regresión en paralelo. En paralelo significa que, si algo falla, no impide la ejecución de otras builds que estén bajo este Stage. Acá lo ven más claro.


Ahh...ese Jenkins se ve un poco diferente, ¿no? Ojo, ¡sigue siendo Jenkins! Solo que con el plugin de Blue Ocean. Lo que hace es dar una interfaz un poco más amigable que la que viene por default con la herramienta y fue algo que se me ocurrió para facilitar el trabajo de los que iban a monitorear y ejecutar estos pipelines, ya que no es un grupo con conocimientos técnicos y Jenkins, como todos sabemos, puede ser un poco duro de roer para ese público, miren sino en comparación:



Para terminar de simplificar el asunto, creé otra página de Confluence con unos dropdown para seleccionar qué Pipeline ejecutar en función de qué tarea de patching se quería probar. De ahí se los mandaba directamente a la vista Blue Ocean del pipeline y podían mandar a correr builds. Un pequeño injerto que tuve que hacer fue generar un output con el link al reporte de Cucumber de cada job, para poder ver rápido y fácil qué falló, dónde y por qué.

Cosas que quedaron en el tintero y conclusión. 

Si bien pude influir bastante en todos estos importantes cambios en la organización, algunas cosas no se pudieron hacer como quería debido a limitaciones en el contexto del cliente. Por ejemplo...yo quería que en los scripts para el deploy que usaban los devs (algunos usando Ansible), se incluya el Request con el token de un usuario genérico con permisos para mandar a correr el pipeline asociado al parche. En teoría esto está perfecto y se mueve en la dirección DevOps que todos sueñan tener, pero la verdad es que a veces el servidor devolvía códigos 500 de entre cientos de tests, haciendo fallar el pipeline entero y, si la condición para el deploy era que los tests pasen, muchas veces un pequeño lapsus del servidor iba a impedir el Deploy sin motivos suficientes. Si...se que los 500s no deberían ser algo que pase pero bueno, están ahí.

La otra limitación era que mucho del desarrollo está outsourceado (Oxford me debe odiar a esta altura) y no era posible tener ningún control ni manejo sobre cómo ejecutan sus scripts ni sus procesos de SCM. Así que esa parte queda, de momento, como manual. Pero lo bueno es que es un click solo que genera una cantidad monumental de trabajo y ahorra muchísimo tiempo a una cantidad significativa de personas! 

¿Y ustedes? ¿Qué cosas tuvieron que crear para sus ambientes de trabajo? Si te resultó entretenido o querés preguntarme algo, podés dejar tu comentario abajo! 

Publicar un comentario

0 Comentarios