4 MÉTRICAS IMPORTANTES PARA LA ENTREGA

CONTINUA
Alison Polton-Simon

Es imposible mejorar lo que no se puede medir. - Peter Drucker

Esta cita refleja la importancia de las métricas en todos los dominios en este
momento. Intuitivamente, esta declaración resuena en todos nosotros. ¿Cómo sabes si
estás creciendo si no tienes los datos para entender dónde has estado y hacia dónde
vas? Esta publicación de blog habla sobre la importancia que vemos de las métricas,
particularmente en la entrega continua.

¿Cómo importan las métricas en el contexto de la entrega continua?

¿Qué te permite saber si realmente has logrado un buen estado de entrega
continua? Para comprender las respuestas a estas preguntas, el equipo de GoCD
entrevistó a consultores, desarrolladores, equipos de operaciones y personas en cada
intersección de DevOps. También hablamos con las partes interesadas del negocio,
porque parte de la entrega continua exitosa es poder colaborar exitosamente entre el
negocio y la tecnología, y ser capaces de comunicar el valor de algunos de los trabajos
subyacentes que intervienen en la implementación de la entrega continua.

Hay cuatro métricas que sintetizamos a partir de esto que creemos que son realmente
valiosas:

 Número de compilaciones listas para implementar

 Tiempo del ciclo
 Tiempo medio entre fallos
 Tiempo medio para recuperarse

¿Cuántas construcciones listas para implementar tienes?

Para una entrega continua exitosa, necesita confirmaciones de rutina y, específicamente,
compromisos de rutina para dominar. Si me estoy comprometiendo todo el tiempo con
mi propia rama personal, no estoy agregando valor al código que está realmente listo
para producción.

Una buena tasa de compilaciones listas para implementar también se basa en tener
pruebas en las que pueda confiar. Un anti-patrón común que escuchamos fue la
existencia de pruebas que tienen que ejecutarse durante varias horas, o incluso un día
entero para hacer la validación. En muchos casos, estas pruebas no fueron confiables, lo
que significa que al final de ese período, no está más seguro de lo que era al
principio. Eso se vuelve costoso porque hace que todos desconfíen de lanzar alguna
vez. La implementación de software puede parecerse a la ruleta rusa.

Esta métrica también enfatiza la importancia de la colaboración entre los roles de

producto y de ingeniería. Los equipos interfuncionales deben ser capaces de crear una
hoja de ruta de tal forma que en cualquier punto las historias se dividan lo
suficientemente pequeñas como para poder liberarlas y brindar valor real a los
usuarios. Si el lado del producto no está involucrado en esto, los equipos desarrollan
acumulaciones de grandes cantidades de trabajo que no agregan ningún valor hasta el
final del juego.

Como complemento de la planificación cuidadosa de la hoja de ruta, el equipo de

desarrollo debe emplear patrones como los alternadores de características, que permiten
desplegar las características sin exponerlas a los clientes.

¿Cuál es tu tiempo de ciclo?

El tiempo de ciclo largo fue el punto de dolor más común que escuchamos de los
desarrolladores. El tiempo desde que se realiza una confirmación, a través de pruebas y
validación, hasta una implementación puede ser una enorme fuente de frustración para
un desarrollador. Como ingeniero, la espera de comentarios requiere un cambio de
contexto disruptivo y representa un desperdicio de tiempo. Una representación ligera,
pero muy real de esto es un comic clásico de XKCD sobre lucha de espadas mientras se
espera la compilación del código.

Este tiempo muerto no lo acerca más a la entrega de valor real a los usuarios, y puede
crear una pérdida de enfoque. Mejorar el tiempo de ciclo de un equipo se basa en
pruebas eficientes y en obtener retroalimentación tan rápido como sea posible. Aquí hay
algunas prácticas que pueden ayudarlo a mejorar su tiempo de ciclo.

1. Ejecutar las pruebas de la unidad al principio de la canalización y las pruebas

complejas de ejecución más avanzada, proporcionará comentarios esenciales
antes y le ahorrará tiempo.
2. Pasar dependencias desde el escenario de la tubería al escenario de la tubería
puede ayudar a evitar la reconstrucción innecesaria de artefactos, que pueden ser
realmente valiosos.
3. Paralelizar sus construcciones cuando sea posible también proporciona ahorros
significativos.
 4. Por último, asegúrese de tener los recursos de compilación correctos para que
cualquier compilación que necesite ejecutar tenga suficientes agentes para hacer
el trabajo.

¿Cuál es tu tiempo medio entre fallas y el tiempo medio de

recuperación?
El tiempo medio entre las fallas y el tiempo medio de recuperación a menudo van de la
mano porque es importante equilibrarlas. El tiempo medio entre fallas le recuerda al
equipo que mantenga la estructura verde siempre que sea posible, y para evitar fallas
fáciles. Sin embargo, solo mirando el tiempo promedio entre las fallas y tratando de
evitar fallas por completo puede resultar en que los equipos sean demasiado cautelosos
y nunca publiquen nada nuevo. El punto central del desarrollo de software es
proporcionar un nuevo valor a los usuarios y asegurarse de que estamos satisfaciendo
sus necesidades. Por lo tanto, centrarse en el tiempo medio de recuperación, una medida
que representa la capacidad de recuperarse de un error, es un contrapeso clave.

Lograr un buen tiempo medio entre fallas se basa en obtener retroalimentación desde el
principio y asegurarse de que la validación completa ocurra en los entornos de
prueba. Estas validaciones deben ejecutarse en entornos similares a la producción con
datos realistas. Las construcciones locales fuertes también son cruciales aquí.

Como la falla es inevitable, es importante asegurarse de que el tiempo medio para

recuperarse sea lo más rápido posible. ¿Cuánto tiempo lleva volver a una versión
ecológica después de que se produjo un fallo en la interconexión o después de que se
produjo un error en la versión? La supervisión robusta de la producción es esencial. Los
equipos deben aprender sobre las fallas a través de su monitoreo y alertas, no a través de
las quejas de los clientes.

Las prácticas clave de perforación, como el retroceso, también pueden mejorar el

tiempo medio de recuperación. Tener un proceso de reversión automatizado puede
hacerte perder un poco de tiempo para entender dónde ocurre el problema. El
diagnóstico de la causa de un problema rápidamente también se basa en el registro
informativo que permite a los desarrolladores identificar un problema cuando han sido
localizados a las 2:00 a.m.

Resumen
Volviendo a la cita de Peter Drucker, para mejorar cualquier cosa, primero debe
encontrar una forma de medirlo y hacerlo visible. Es por eso que tener un tablero y
hacer visibles las métricas para el equipo les da un sentido de propiedad y un sentido de
conexión que es realmente valioso. Por otro lado, no quiero decir que las métricas son
una panacea. Definitivamente hay algunas métricas y métricas de vanidad sin
sentido. En última instancia, desea incentivar a las personas a que examinen los
problemas difíciles, y donde puedan crear un significado para el equipo u organización.