DevOps en Podemos TI

Terminamos la serie para hablar de DevOps en Podemos TI. Vamos a hablar ahora sí de cómo hemos ido aplicando todo esto...

La primera parte la pueden leer aquí.

La segunda parte la pueden leer aquí.


DevOps en Podemos TI

Podemos TI

Y por fin, ¿todo esto cómo nos ha ayudado?

Conocía DevOps de oídas desde hace ya unos cuantos años, y por lo que sabía de él lo que se necesitaba era tener Integración y Despliegue Continuo. De esa forma, para mediados del año pasado, 2019, nuestro sistema ya tenía, por lo menos, bastantes pruebas unitarias implementadas que se ejecutaban automáticamente con cada push y merge en el repositorio de código.

Desde hace varios años también, venimos usando Gitlab como herramienta, sobre todo para gestionar nuestros repositorios de código. Resulta que Gitlab tiene ya algunos años haciendo mejoras y de ser sólo un gestor de repositorios con git ya es una herramienta DevOps bastante avanzada. Por supuesto que existen otras, Jira de Atlassian es la más famosa, pero como ya andábamos con Gitlab desde antes, ahí nos hemos quedado.

Cuando salieron los pipelines en Gitlab, una feature que permite ejecutar código sobre los cambios que se hagan en el repositorio, implementamos casi de manera experimental la ejecución de las pruebas unitarias. No voy a presumir de la calidad de nuestras pruebas, ni de antes ni de ahora. Nuestro sistema está construido sobre una arquitectura de capas. En lo que nos concentramos, por ser vital para el negocio, fue en darle prioridad a la cobertura de pruebas en la capa del Negocio, mientras que las capas de Modelo y de Interfaz han quedado un poco relegadas. Así que, a mediados del año pasado, teníamos al menos esto:

  • Gitlab como gestor de repositorios
  • Pipelines para ejecutar pruebas unitarias de la capa de Negocio de nuestro sistema
  • Usábamos un esquema de dos branches para nuestros releases: Review para hacer revisión por pares de todos los cambios antes de subir a producción, y Master, que es el que subimos a producción. Esta es una de las prácticas más antiguas que ya teníamos establecidas en el equipo. Prácticamente desde que dejé de ser sólo yo, y comenzamos a ser dos y luego más desarrolladores.
  • Cobertura de pruebas unitarias incompleta, quizá de entre 50 y 60% (nunca lo medimos en ese entonces) del proyecto principal de la capa de Negocio del sistema.
  • Frecuencia de despliegues: en teoría podíamos desplegar cuando quisiéramos, pero con despliegues manuales al servidor
  • Tiempo de espera entre desarrollo y despliegues: sin métricas y arbitrario. Podía pasar poco tiempo, o mucho dependiendo de nuestra carga de trabajo. A veces sí pasaban días.
  • Tiempo para restaurar un servicio con problemas: procurábamos que fuera el menor posible, podría ocurrir en menos de un día. Usualmente en medio día. Rara vez varios días. Nunca que yo recuerde más de una semana.
  • Ratio de cambios que fallan: difícil saberlo con precisión dado que no medíamos casi nada, pero estimo por la cantidad de veces que llegamos a tener fallos que teníamos un ratio bajo, quizá rozando el 15% requerido por DevOps.

The DevOps HandbookFue con ese estado de cosas con los que me topé, ahora si de lleno, con el mundo DevOps. Comenzó antes de la mitad del año pasado, con la genial intención de nuestro director de regalarnos dos libros: precisamente "The Phoenix Project", y luego "The DevOps Handbook" (del mismo autor y ya no novelado, más técnico y mucho más rico).

Cuando terminé "The Phoenix Project", me puse a investigar, y entonces me topé con el estudio The State of DevOps 2019 de DORA (DevOps Research & Assessment) y Google. Ya no tenía vuelta atrás... comencé a leer "The DevOps Handbook" pero como siempre me pasa con estas cosas, me tardé más en leerlo, aunque conforme avanzaba afianzaba lo que ya tenia pensado y planeado...

En noviembre-diciembre del 2019 reuní a mi equipo y organicé lo que llamé el State of DevOps de Podemos TI 2019, donde además de explicarles en qué consiste DevOps, las Tres Vías, y el diagnóstico de donde creía yo que estábamos (básicamente los incisos que comenté anteriormente), con su genial retro aterrizamos muchas ideas y cosas pendientes por hacer.

Ha pasado casi un año desde eso, y hoy, éste es más o menos nuestro estatus:

  • Seguimos usando Gitlab. Conseguimos licencia Starter, para poder aprovechar varias features que nos son de utilidad. No me gusta mucho porque no es una herramienta libre per se, pero la alternativa nos estaría llevando mucho tiempo ahorita. Ya iremos viendo luego.
  • Nuestros pipelines ya no sólo ejecutan pruebas unitarias. Ahora primero ejecutan linters, para verificar ciertas convenciones de código, después pruebas unitarias, con análisis de cobertura incluido para fines estadísticos. Esto en cuanto a Integración Continua.
  • Dejamos a un lado el branch Review que usábamos para la revisión por pares. La verdad es que nos dimos cuenta que sólo nos atrasaba porque una vez pasado un cambio a Review, luego alguien tenía que pasar eso a Master. Y ese alguien siempre era yo. Así que nos quedamos con un sólo branch persistente: Master. Eso en la práctica es Trunk Based Development :-D
  • Cobertura de pruebas unitarias ya medida en todos nuestros proyectos que cuentan con pruebas unitarias. Nos faltan proyectos por probar, y nos falta cobertura por lograr. Estamos en un promedio de 40% de cobertura de todos los proyectos, y de 75-85% en los proyectos más probados.
  • Frecuencia de despliegues: estamos ya en un promedio de 10 despliegues por semana, lo que representa un promedio de 2 despliegues diarios.
  • Tiempo de espera entre desarrollo y despliegues: estamos logrando desplegar cambios en menos de un día, con proceso de revisión por pares incluído. Además ya implementamos Entrega Continua en todos los proyectos que la infraestructura que tenemos nos permite, que son la gran mayoría. Aún hacemos uno que otro despliegue manual, en proyectos que casi no sufren cambios y que cuya infraestructura, dada por un proveedor externo, no nos permite aún automatizar.
  • Tiempo para restaurar un servicio con problemas: tenemos implementado un sistema Desk con políticas de SLA definidas. Nos falta un poco de métrica ahí, pero prácticamente todos (aunque no el 100%) los tickets que se levantan se atienden en menos de 1-2 horas.
  • Ratio de cambios que fallan: mantenemos un contador de bomberazos provocados por nosotros (ya lo teníamos desde hace mucho, pero lo refinamos), y tenemos por objetivo actualmente llegar a 90 días sin ningún error provocado por nosotros, bajo ciertos lineamientos. Cuando llegamos a 90 días nos subimos la barra y reiniciamos el contador. Estamos a punto de llegar a 90 días por tercera vez en el año. No estamos aún en el punto de considerar cualquier error nuestro como determinante del contador: nuestros parámetros incluyen desde el tiempo que nos lleve resolver una incidencia que hubiéramos provocado nosotros (máximo 1 hora), que en la solución se involucre más de una persona, que la incidencia ocurra fuera de nuestro horario laboral, y claro, que cualquier usuario se altere por la incidencia provocada
  • Implementamos la herramienta SonarQube para monitorizar métricas de calidad de nuestro código, desde cobertura de pruebas unitarias hasta el grado de fiabilidad, seguridad y mantenibilidad de nuestro código. Esto nos da visibilidad y nos permite mejorar aún antes de que se presente la necesidad de hacerlo. Por supuesto, esto beneficia el Third Way.

Así que hemos avanzado muchísimo en el año.

En lo que concierne a las Tres Vías

  • La integración continua es cada vez mejor; la entrega continua está casi completa; trunk based development es prácticamente una realidad; el release continuo va sucediendo cada vez más con feature toggles.
  • Los logs siempre han estado presentes; SonarQube es un gran paso para lograr visibilidad.
  • Subirnos la barra cada que llegamos a 90 días sin bomberazos nos permite implementar mejoras; estamos implementando sesiones de enseñanza y aprendizaje por lo menos tres veces al mes.

¿Qué pendientes nos quedan?

Muchísimos...

  • Queremos más y mejor Integración Continua. Mejores linters. Asegurar cierta cobertura en pruebas unitarias. Los proyectos que aún no tienen pruebas unitarias son nuestro gran faltante. Queremos estar tan seguros de nuestras pruebas para poder sentirnos cómodos ejecutándolas en Producción.
  • Queremos Entrega Continua en todos nuestros proyectos de ser posible, y llegar a Despliegue Continuo en algún momento.
  • Tenemos que cambiar nuestra Arquitectura. La entrañable por Capas nos ha servido mucho y muy bien, y para el tamaño que tiene la empresa aún escala muy bien. Sin embargo, como queremos acelerar el ratio de desarrollo y mejorar nuestras métricas DevOps, eso implica tener una infraestructura que facilite la entrega de cambios sin afectar a otros. Microservicios probablemente sea el camino.
  • Y para lograr microservicios, contenerización en la gran mayoría de nuestros servicios.
  • Nos falta mucho para tener más visibilidad. Ya estamos jugando con herramientas para implementar en los servidores. Pero aún así, la arquitectura puede volver a jugar en contra de lograr una mejor implementación que, quizá, contenedores y microservicios nos podrían dar.
  • Aspiramos a que las métricas que nos da SonarQube se vean perfectas todo el tiempo, y que se vuelva una herramienta no sólo de monitoreo sino que rija también el hecho de si un cambio puede o no pasar a Producción, dependiendo si impacta en sus métricas.
  • Y un largo etcétera, estos son los que me vienen a la mente ahora...

En fin, que DevOps se ha vuelto en un verdadero parteaguas para nosotros. Tanto así que incluso lo incluimos en la lista de nuestros valores. Pocas cosas podrían provocar un cambio así, el hecho de que DevOps haya llegado hasta ahí habla del verdadero impacto que vemos en él para nosotros y nuestro trabajo.


Si quieres ver las partes anteriores de esta serie:

La primera parte la pueden leer aquí.

La segunda parte la pueden leer aquí.

Etiquetas