Las métricas DORA
No hace muchas semanas, publiqué un capítulo en Querída Tecnología, nuestro podcast, hablando sobre las métricas DORA. Al igual que hoy no he podido evitar ponerle a este artículo una cabecera en la que aparece Dora la Exploradora, en aquel momento tampoco pude evitar hacer algún chiste fácil con el personaje de dibujos animados. Me esforzaré por evitar este tipo de ocurrencias en este artículo, aunque no prometo nada.
Volviendo a las métricas, para mi sorpresa, ese capítulo en Querída Tecnología tuvo mejor acogida de la esperada y, desde entonces, he recibido algunas preguntas y bastante feedback sobre este tema, así que, para evitar que ese audio se pierda en solitario en medio del caos de internet, me ha parecido buena idea incorporar el contenido también en este blog para que texto y audio puedan perderse en compañía.
Al grano. Si eres un apasionado del mundo del desarrollo de software y estás interesado en los procesos de CICD, seguramente has escuchado hablar de las famosas métricas DORA. Pero, ¿qué son exactamente?
Las métricas DORA son un conjunto de indicadores clave que nos ayudan a evaluar la eficiencia y calidad de nuestros procesos de desarrollo de software. El término DORA proviene de DevOps Research and Assessments, y, aunque no sabría muy bien cómo traducirlo al español, fue acuñado por Google en el año 2019.
La finalidad de estas métricas es que los distintos equipos que participan en los procesos de desarrollo de software puedan identificar y eliminar cuellos de botella, evaluar la eficiencia de sus procesos de entrega de software y, por último, mejorar la calidad del software que se entrega. Y todo esto, con tan solo cuatro métricas.
- Frecuencia de despliegues: Cada cuanto se realizan despliegues en producción.
- Tiempo de puesta en marcha de los cambios: El tiempo que tarda un commit en llegar a producción
- Tasa de despliegues fallidos en producción: Porcentaje de veces en las que un despliegue rompe cosas en lugar de arreglarlas u ofrecer nuevas funcionalidades.
- Tiempo de restauración del servicio: Cuánto tiempo necesitamos para recuperarnos de un fallo en producción.
Veamos cada una de ellas con más detalle.
Frecuencia de despliegues
Esta métrica mide la regularidad con la que un equipo despliega código en diferentes entornos, ya sea en desarrollo, en un entorno de pruebas o en producción, siendo especialmente relevante el valor para este último. Cuanto mayor sea la frecuencia de despliegues, mayor será la capacidad del equipo para entregar cambios de manera continua, si bien obtener los valores esperados en esta métrica no garantiza para nada la calidad de esas entregas. Por tanto, es una métrica enfocada principalmente en la agilidad de los equipos de desarrollo y de los procesos de CICD, pero no es una medida de calidad.
La manera de calcular esta métrica es bastante sencilla ya que basta con saber el número de despliegues que se realizan en un plazo concreto de tiempo. Teniendo en cuenta lo rápido que cambia el mundo de la tecnología y la cantidad de novedades que podemos encontrarnos día a día, el hecho de ser capaz de evolucionar nuestra solución con agilidad y de llegar cuanto antes al mercado, puede significar una gran ventaja competitiva, de ahí la importancia de medir la frecuencia de despliegues para poder evaluar la eficacia los procesos de desarrollo y entrega de software y poder analizar tendencias a lo largo del tiempo. Lejos van quedando ya aquellos tiempos en los que poner una nueva funcionalidad en producción implicaba trabajar a horas intempestivas durante horas.
Algunos consejos que pueden ayudarnos a mejorar esta métrica son:
- Automatización de todo el ciclo de CICD
- Utilizar arquitecturas modulares o de microservicios para poder desplegar pequeñas partes del sistema de manera autónoma.
- Pruebas Automatizadas que nos den tranquilidad a la hora de llegar a producción.
- Fomentar y promover una cultura de colaboración y comunicación entre los equipos de desarrollo, operaciones y calidad, facilitando la coordinación y el intercambio de conocimiento para agilizar el proceso de despliegue.
- Revisar y optimizar estos procesos de manera periódica.
Tiempo de puesta en marcha de los cambios
Esta métrica también es crucial para medir la agilidad de una compañía, ya que evalúa el tiempo que transcurre desde la implementación de un cambio hasta que éste llega al entorno productivo para que los usuarios finales puedan beneficiarse de las mejoras.
Es cierto que sacar este valor suele ser complejo, ya que detectar de manera automática cuánto tiempo pasa desde que se escribe un código hasta que se despliega en producción requiere la integración de varias herramientas involucradas en el ciclo de CICD, pero, por suerte para todos nosotros, hoy por hoy somos capaces de integrar información de casi cualquier fuente.
De esta manera, podremos detectar de manera fácil dónde se invierte una mayor cantidad de tiempo y buscar vías de mejora: ¿tardamos mucho en aprobar los merge request?, ¿la validación en entornos previos no es lo suficientemente rápida?, ¿no hay bastantes tests automatizados?
Tasa de despliegues fallidos en producción
La calidad del trabajo realizado se ve reflejada en la tasa de despliegues fallidos en producción. Esta métrica evalúa la proporción de despliegues con errores que afectan al servicio en comparación con los despliegues exitosos. Un valor bajo en esta métrica sugiere que el equipo está entregando cambios de manera confiable y de calidad.
Para mejorar esta métrica, es fundamental tener definidas pruebas rigurosas, tanto automatizadas como manuales, y mantener un equilibrio entre la velocidad de entrega y la calidad del producto.
Al llevar esto a la práctica, en muchas ocasiones nos encontramos que el problema de esta métrica está más en el plano teórico que en el plano técnico. Es decir, al definir qué entendemos por un despliegue fallido. ¿Es sólo un despligue que rompe el sistema y corta el servicio o es un despliegue que genera un bug que afecta a los usuarios?. La buena noticia, es que podemos interpretar y adaptar este concepto según nuestras necesidades y el impacto que este despliegue pueda tener en los usuarios finales.
Personalmente, me gusta entender como despliegue fallido aquel que no hace lo que nosotros esperamos, bien sea porque produce un corte en el servicio (que sería el escenario más grave), o bien porque genera un error que hace que una parte de nuestra aplicación no funcione o lo haga de manera incorrecta.
Tiempo de restauración del servicio
El tiempo de recuperación o restauración es un indicador que nos permite evaluar la capacidad de un equipo para responder rápidamente a incidentes y mantener la disponibilidad de los servicios. Cuanto menor sea el tiempo de recuperación, menor será el impacto de los fallos en la experiencia del usuario y en el funcionamiento del sistema.
Poner en marcha un buen sistema de monitorización y observabilidad, así como contar con planes de contingencia bien definidos, son estrategias efectivas para reducir el tiempo de recuperación ya que, para bien o para mal, no todos los errores se pueden encontrar en el momento de hacer un despliegue.
En ocasiones, para detectar algunos errores, tenemos que hilar mucho más fino. Darnos cuenta de que determinadas interacciones de los usuarios se han reducido o que cierto formulario que antes recibíamos con frecuencia hemos dejado de recibirlo. De ahí la importancia, no solo de tener un buen sistema de observabilidad habilitado, sino también de realizar de manera automatizada tests sobre nuestras aplicaciones.
Conclusión
En resumen, las métricas DORA son una herramienta valiosa para evaluar la eficacia y calidad de nuestros procesos de desarrollo de software. Al medir y entender estas métricas, podemos identificar áreas de mejora, establecer objetivos claros y trabajar en la mejora continua de nuestros equipos. Recuerda que no se trata solo de números en una pantalla, sino de indicadores muy valiosos para evaluar la salud y efectividad de los procesos de desarrollo de software. Y recuerda también que no hay un número mágico a partir del cual todo está bien o mal, sino que cada caso es diferente. La idea es poder medir, comparar y, por supuesto, seguir mejorando.
La implementación efectiva de las métricas DORA no solo nos ayuda a optimizar nuestros procesos, sino que también nos guían para conseguir una mayor calidad en nuestros desarrollos e impulsan la innovación constante. Pero, ¡cuidado!, también son un arma de doble filo. Debemos de entender estas métricas como un conjunto y no caer en el error de centrarnos únicamente en un indicador para llevarlo a la excelencia, porque podríamos convertirnos en los más rápidos distribuyendo software de mala calidad o, por el contrario, en los más lentos poniendo en marcha aplicaciones de una calidad sobresaliente. Mi consejo es trabajar de manera paralela en la mejora de cada una de las métricas, buscando pequeños puntos de mejora que impliquen la mejora global de nuestros ciclos de desarrollo de software.
Para terminar, únicamente señalar que, dada la naturaleza diversa de estas métricas, no siempre es fácil obtener los datos necesarios para calcularlas, pero si conseguimos hacer que nuestras herramientas de CICD y control de versiones se entiendan entre ellas, el resto es pintar y colorear. En mimacom hemos ayudado a varios clientes a calcular y publicar estas métricas, generando dashboards tanto usando el stack de Elastic como el de Grafana pero, por supuesto, lo que sobran son opciones.
¿Y vosotros?, ¿qué tal vuestros procesos de desarrollo de software?