Métricas de DevOps Research and Assessment (DORA) para mejorar los procesos de desarrollo.

¿Que es DORA?

Un buen punto de partida para comenzar a medir y mejorar los flujos de desarrollo de una organización es a partir de los resultados del estudio de DevOps Research and Assessment mas comunmente conocido como DORA (https://www.devops-research.com/research.html) realizado por Google. DORA es un estudio realizado durante mas de 6 años donde han participado miles de DevOps engineers y Leaders.

El resultado es que DORA propone 4 metricas principales para medir una organización:

1. Deployment Frequency: Con que frecuencia una organizacion despliega releases a produccion con éxito.
2. Mean Lead Time for Changes: Cuanto tiempo pasa para que un cambio de código (commit) llegue a producción.
3. Mean Time to Recovery (MTTR): Porcentaje de despliegues que fallan en producción.
4. Change Failure Rate: Cuanto tiempo transcurre para recuperar producción de un fallo.

Las dos primeras métricas (Deployment Frequency, Mean Lead Time for Changes) miden la velocidad del equipo de desarrollo, mientras que MTTR y Change Failure Rate son una media de la calidad y estabilidad de un proyecto de desarrollo. Las 4 metricas pueden ser extraidas de las herramientas que se estén utilizando para manejar el proceso de desarrollo: Jira, Git, Jenkins, entre otras.

Estas 4 metricas propuestas por DORA están diseñadas para permitir a los Software Developers alinear su trabajo con los objetivos de negocio. Son un standard para que CTOs y VPs of Engineering puedan tener un overview de alto nivel de como sus organizaciones estan trabajando.

Al disponer de las metricas de DORA y centrando los esfuerzos en mejorarlas. Los equipos de desarrollo son conscientes que estan haciendo lo correcto para desarrollar sus proyectos y para mejorar su negocio.

Antes de comenzar es importante explicar a la organizacion que miden realmente estas métricas y que significan para que sean útiles al interpretarlas para la toma de decisiones.

Deployment Frequency

Mide el numero de veces que el código es desplegado en producción. Generalmente se mide por “Deployments Per Day”.

Producción puede significar cosas diferentes dependiento la compañía. Para una compañia con un producto SaaS, significa desplegar código sobre la plataforma de producción que usan sus clientes y para otras compañías puede significar desplegar una vesion para ser usada por los usuarios.

¿Por que es importante “Deployment Frequency”?

Incrementar la frecuencia de despliegue es indicio de eficiencia y confianza de los equipos en sus procesos de desarrollo. Un equipo que es capaz de desplegar con más frecuencia está siendo más rápido y eficiente en todas las etapas de desarrollo.

¿Como se calcula “Deployment Frequency”?

Cuenta el número total de despliegues de una organización durante un sólo día. La definición de un “deployment” puede variar según la organización pero esto no afecta.

Esta métrica suele ser obtenida si la organización tiene un Continuous Integration/Continuous Delivery(CI/CD) platform que tenga un API para poder extraer este valor.

¿Como se mejora “Deployment Frequency”?

Para mejorar la frecuencia de despliegue es importante invertir en mejorar:

• Integrar herramientas CI/CD en todo el ciclo de desarrollo
• Automatización para la cobertura de test
• Automatizar la fase de validación de una release y creación de la misma
• Implentar procesos de Rollback para reducir los tiempos de recuperación ante un error en producción tras una release.

Mean Lead Time for Changes

Es el tiempo medio que tarda desde que se entrega código hasta que se despliega en producción.

Algunas organizaciones miden este valor desde que se realiza el commit hasta el merge (fusión) del código en la rama principal que será desplegada en producción.

¿Por que es importante “Mean Lead Time for Changes”?

Un valor bajo en Mean Lead Time for Changes significa que los equipos son eficientes al codificar, desplegar sus proyectos y añadiendo valor a su producto.

Intentar reducir este tiempo de promedio de entrega obliga a los equipos a dividir adecuadamente el trabajo, revisar mineciosamente su código y asi disponer de un desarrollo de más calidad además de rápido.

¿Como se calcula “Mean Lead Time for Changes”?

Cada desarrollo / proyecto se mide de principio a fin y se calcula un promedio de esos tiempos.

¿Como se mejora “Mean Lead Time for Changes”?

Esta metrica puede ser mejorada por:

• Automatizar los procesos de despliegue
• Asegurar que los procesos en la plataforma de CI/CD son lo mas eficientes posibles.
• Romper los desarrollos en trozos más pequeños y manejables
• Crear procesos de “Code Review” eficientes para reducir el tiempo de entrega.

Mean Time to Recovery (MTTR)

Esta metrica mide el tiempo medio que necesita un equipo para recuperar el sistema desde que se produce un fallo.

“Fallo” puede significar cualquier cosa, desde un bug en producción, hasta que el sistema de producción esté sin servicio (outage).

¿Por que es importante “Mean Time to Recovery”?

Es evidente que un tiempo sin servicio no es bueno, y cuanto mas rápido vuelva a prestar servicio mejor.

Teniendo en mente el tiempo de recuperación en etapa diseño e implementación dará como resultado sistemas más robustos y resilientes.

Tiempos de recuperación rápidos, indican que los equipos son eficientes en el diagnóstico de los problemas y su corrección.

Medir este tiempo tiene un efecto en los equipos que acen que sean mas cuidadosos y preocupados por la calidad durante todo el proceso de desarrollo.

¿Como se calcula “Mean Time to Recovery”?

Esta métrcia es trackeada midiendo el tiempo medio entra que se reporta un incidente en producción y hasta que es resuelto.

¿Como se mejora “Mean Time to Recovery”?

La métrica MTTR puede ser mejorada:

• Asegurando procesos para recuperación automatizados para ser ejecutados de forma inmediata en caso de error.
• Disponer de un sistema completamente monitorizado
• Disponer de una plataforma AIOPS, implementando procesos de predicción de un comportamiento anómalo de los sistemas en el futuro.
• Reduciendo los tiempos de despliegue para aplicar parches.
• Priorizar la recuperación del sistema sobre cualquier tarea de los equipos.

Change Failure Rate

Mide con que frecuencia un cambio de código provoca un fallo en producción. Cambios que producen rollback, que el sistema falle en producción o que se detecte un bug provocado por los últimos cambios.

¿Por que es importante “Change Failure Rate”?

Esta métrica es importante porque todo el tiempo dedicado a resolver un problema es tiempo que no se está usando en liberar nuevas funcionalidades que aporten valor al negocio. Siempre es deseable reducir el número de problemas en los desarrollos.

¿Como se calcula “Change Failure Rate”?

Normalmente, esta métrica se calcula contando el numero de veces que un despliegue acaba en un error y divido por el numero total de despliegues para obtener un valor medio. Un valor medio bajo será siempre bueno.

¿Como se mejora “Change Failure Rate”?

Change Failure Rate puede verse reducido si se mejora:

• Asegurar que todo el codigo esta cubierto por test automatizados.
• Mejorando los procesos de CI para incorporar y ejecutar los test implementados.
• Realizando revisiones de código exhaustivas y completas para ayudar a evitar que se produzcan errores en producción.
• Análisis de dependencias y sistemas sensibles a ser afectados por un cambio.

Conclusion

Si se consigue medir con las metricas propuestas por DORA proporcionará a la organización una información muy valiosa para tomar mejores decisiones sobre donde y como mejorar sus procesos de desarrollo. Estas métricas suelen revelar cuellos de botella en los que el proceso de desarrollo suele atascarse.

El seguimiento de las metricas de DORA puede ayudar a poner el foco de los equipos de desarrollo y negocio en las cosas que realmente proporcionan valor al negocio. Las decisiones que se tomen basadas en estas métricas serán medibles. Acabando asi con las tomadas que no se puede medir su impacto de mejora.

DORA mide el valor que ofrece los equipos, si las metricas son buenas una organización puede estar segura que se está aportando valor en las entregas y asegurando su calidad para evitar errores que provoquen perder el foco de lo realmente importante que es aegurar la continuidad del negocio y aportando valor en cada entrega.