Medir el éxito de DevOps con los últimos datos de entrega de software

Para medir el éxito de DevOps, necesita puntos de referencia de la industria para cuantificar métricas clave de éxito en la entrega de software. Este año, establecimos los primeros puntos de referencia para los equipos que practican CI / CD , basados ​​en 55 millones de puntos de datos de más de 44,000 organizaciones en nuestra plataforma. ¿Qué aspecto tienen los equipos de ingeniería de alto rendimiento, cuantitativamente?

Como el proveedor de CI independiente más grande del mundo, tenemos una oportunidad única de investigar cómo se ve la entrega de software cuantitativamente: en decenas de miles de equipos, compromiso por compromiso. Con datos de entrega reales, podemos ver cómo los equipos están construyendo e implementando software en la práctica.

La capacidad de su equipo para cumplir es una ventaja competitiva. ¿A qué números debería apuntar para mantenerse a la vanguardia?

4 puntos de referencia clave para medir a su equipo

Nuestros datos completos sobre el rendimiento del equipo de ingeniería han identificado estos cuatro puntos de referencia para equipos de software de alto rendimiento:

• Rendimiento: la cantidad de ejecuciones del flujo de trabajo importa menos que estar en un estado listo para la implementación la mayor parte o todo el tiempo
• Duración: los equipos quieren apuntar a duraciones del flujo de trabajo en el rango de cinco a diez minutos
• Tiempo medio de recuperación: los equipos deben intentar recuperarse de cualquier ejecución fallida reparándola o revirtiéndola en menos de una hora.
• Tasa de éxito: las tasas de éxito superiores al 90% deberían ser su estándar para la rama predeterminada de una aplicación

¿Cuál es el propósito de medir cada una de estas métricas de éxito? Echemos un vistazo más profundo a lo que significan estas métricas y por qué son tan valiosas para su equipo.

Métrica clave: duración

La duración se define como el tiempo que tarda en ejecutarse un flujo de trabajo. Es la métrica más importante de la lista porque la creación de un ciclo de retroalimentación rápido (incluido el rendimiento y el tiempo medio de recuperación) depende de la duración. En otras palabras, no puede impulsar una solución, ni siquiera una muy necesaria, más rápido que el tiempo que tarda su flujo de trabajo en ejecutarse. La duración también representa la velocidad con la que los desarrolladores pueden obtener una señal significativa (“¿mi flujo de trabajo pasó o falló?”). Una duración corta requiere un flujo de trabajo optimizado.

No todos los flujos de trabajo producen el mismo estado final. Por ejemplo, algunos flujos de trabajo solo ejecutan pruebas específicas según la parte del código base de la aplicación que cambió. La duración, por lo tanto, no es una medida explícita de cuánto tiempo lleva implementar en producción. Es solo una medida de cuánto tiempo se tarda en llegar a la conclusión de un flujo de trabajo.

El objetivo final de CI es una respuesta rápida . Una señal de compilación fallida debe llegar a los desarrolladores lo antes posible; no puedes arreglar lo que no sabes. Pero la conciencia no es la única consideración. Los desarrolladores también necesitan información de sus compilaciones fallidas. Obtener la información correcta proviene de escribir pruebas rigurosas para su software.

Es importante enfatizar aquí que la velocidad por sí sola no es el objetivo. 

Un flujo de trabajo sin pruebas puede ejecutarse rápidamente y volverse verde, una señal que no es útil para nadie. Los equipos deben poder actuar ante una falla lo más rápido posible y con tanta información como puedan obtener de la falla. Sin un conjunto de pruebas de calidad, los flujos de trabajo de corta duración no aportan información valiosa al ciclo de retroalimentación. El objetivo, entonces, es una rica información combinada con una corta duración.

Métrica clave: tiempo medio de recuperación

El tiempo medio de recuperación se define como el tiempo medio entre fallos y su próximo éxito. Esta es la segunda métrica más importante de la lista: después de recibir una señal fallida para su equipo, su capacidad para abordar el problema rápidamente es invaluable. Debido a que el tiempo medio de recuperación mejora con una cobertura de prueba más completa, esta métrica puede ser un indicador de cuán bien probada está su aplicación.

Compilación fallida, señal valiosa, solución rápida, compilación aprobada: la integración continua hace posible estos ciclos rápidos de retroalimentación. Las señales rápidas permiten a los equipos probar cosas nuevas y responder a cualquier impacto de inmediato. Asimismo, la cobertura de pruebas sólida reduce el temor de introducir código roto en su base de código de producción, lo que le permite desafiar a sus equipos de ingeniería a ser creativos y ágiles con las soluciones que desarrollan.

Métrica clave: rendimiento

El rendimiento se define como la cantidad promedio de ejecuciones de flujo de trabajo por día. Un flujo de trabajo se activa cuando un desarrollador realiza una actualización de la base de código en un repositorio compartido. Un empujón a su sistema de control de versiones (VCS) activa una canalización de CI que contiene su flujo de trabajo.

El número de ejecuciones del flujo de trabajo indica cuántas unidades de trabajo discretas se mueven a través de su canal de desarrollo de aplicaciones. Un componente del rendimiento refleja el tamaño de sus confirmaciones: ¿está impulsando muchos cambios pequeños o menos cambios grandes? El tamaño correcto dependerá de su equipo, pero el objetivo es tener unidades de trabajo lo suficientemente pequeñas para que pueda depurar rápida y fácilmente, pero lo suficientemente grandes como para implementar un cambio significativo.

Recomendamos monitorear las tasas de rendimiento frente a establecer objetivos explícitos. Es importante ver la frecuencia con la que suceden las cosas, y el rendimiento es una medida directa de la frecuencia de compromiso. Las fluctuaciones en el rendimiento pueden ocurrir en situaciones como la incorporación, donde dos desarrolladores pueden trabajar juntos en las mismas tareas y generar menos confirmaciones como resultado. El establecimiento de métricas de referencia para su organización puede prepararlo para este tipo de impacto, permitiéndole pronosticar la productividad de la ingeniería a través de estos eventos predecibles. Cuando se encuentra con circunstancias imprevistas, su línea de base también puede ayudarlo a determinar el volumen de trabajo que se perdió.

Cuando una aplicación bien probada se encuentra en un estado en el que se puede implementar en cualquier momento, es porque cada nuevo cambio se ha validado continuamente. Sin una tubería de entrega de software completamente automatizada, un equipo está sujeto a implementar emergencias y simulacros de incendio, a menudo en momentos inoportunos (viernes por la noche, por ejemplo).

Con una canalización de entrega de software totalmente automatizada, usted decide con qué frecuencia (y cuándo) se entregan las actualizaciones a sus usuarios finales: arreglos inmediatos; actualizaciones de características a medida que se desarrollan; cambios a gran escala en un calendario establecido por las demandas de su negocio. Un número particular de implementaciones / día no es el objetivo, pero la validación continua de su base de código a través de su canalización sí lo es.

Métrica clave: tasa de éxito

La tasa de éxito se define como el número de pasadas dividido por el número total de pasadas durante un período de tiempo. Los modelos de flujo de Git que se basan en el desarrollo de la rama temática (frente al desarrollo de la rama predeterminada) permiten a los equipos mantener sus ramas predeterminadas en verde.

Una cosa importante a tener en cuenta es que esperamos ver una alta variabilidad de éxito dependiendo de si el flujo de trabajo se ejecuta en la rama predeterminada o temática. En muchos modelos de git-flow, las ramas temáticas son donde se realiza la mayor parte del trabajo y, por lo tanto, la mayoría de los experimentos de aprobación y falla que generan señales.

Al establecer el alcance del desarrollo de características en ramas temáticas, podemos diferenciar entre experimentos intencionales (donde las compilaciones fallidas son valiosas y esperadas) y problemas de estabilidad (donde las compilaciones fallidas no son deseables). La tasa de éxito en la rama predeterminada es una métrica más significativa que la tasa de éxito en una rama temática .

Establezca puntos de referencia de éxito de DevOps para su equipo

Si bien no existe un estándar universal al que todo equipo deba aspirar, nuestros datos y los patrones de entrega de software que hemos observado en nuestra plataforma muestran que existen métricas de ingeniería razonables para que los equipos se establezcan como objetivos. En última instancia, su capacidad para medir su línea de base y realizar mejoras incrementales en estas métricas es más valiosa que perseguir números “ideales”.

Referencia

Traducido al español de Ron Powell. Gerente de marketing de contenido técnico (2020)

https://circleci.com/blog/how-to-measure-devops-success-4-key-metrics/