Medición y monitorización del rendimiento de CI/CD
La mejora continua es una de las piedras angulares de la filosofía DevOps.
Se extiende a todos los aspectos del desarrollo de software, desde el producto o servicio que está creando hasta la cultura y los procesos de su organización.
La mejora continua implica la recogida y el análisis del feedback sobre lo que se ha creado o cómo se está trabajando para entender lo que está funcionando bien y lo que podría mejorarse. Una vez aplicados esos conocimientos, se recopila más feedback para ver si los cambios realizados han reorientado el trabajo en la dirección correcta, y luego se sigue ajustando según sea necesario.
Un proceso de CI/CD desempeña un papel fundamental a la hora de permitir la mejora continua de su software. Al abreviar el tiempo que transcurre desde el desarrollo hasta la implementación, se pueden lanzar cambios para los usuarios con mayor frecuencia, y así obtener información sobre el uso en producción, que sirve para determinar las prioridades. Asimismo, un feedback rápido procedente de cada etapa de pruebas automatizadas facilita la resolución de los errores y le ayuda a mantener la calidad de su software.
Pero la mejora continua no acaba ahí. Aplicando las mismas técnicas al propio proceso de CI/CD, puede perfeccionar el proceso de compilación, prueba y lanzamiento de su software, lo que amplía los bucles de feedback que utiliza para mejorar su producto.
Comprensión de las métricas de procesos
Se suele decir que «No se puede controlar lo que no se mide»,
Las métricas son una herramienta esencial para mejorar el rendimiento del sistema: ayudan a identificar dónde se puede añadir valor y ofrecen una base de referencia para medir el impacto de cualquier mejora efectuada.
El rendimiento en CI/CD abarca tanto la velocidad como la calidad; no debería ser necesario poner en entredicho la implementación rápida de los cambios en pro de la entrega de un producto robusto y fiable: un proceso de CI/CD de alto rendimiento le permitirá lograr ambos.
Al medir y monitorizar la velocidad de las actividades, la calidad de su software y el grado de uso de la automatización, puede identificar áreas de mejora y confirmar si los cambios realizados han surtido un efecto positivo.
Métricas DevOps de rendimiento de alto nivel
Las siguientes cuatro métricas han sido identificadas por DevOps Research and Assessment (DORA) como métricas de alto nivel que indican con precisión el rendimiento de una organización en el contexto del desarrollo de software.
You can learn more about the research that informed these choices in the book Accelerate.
Plazo de entrega
Aunque el plazo de entrega (también conocido como plazo de ejecución o plazo de lanzamiento al mercado) puede medirse como el tiempo que transcurre desde que se plantea una funcionalidad hasta que se pone a disposición de los usuarios, el tiempo que conlleva la concepción, la investigación de los usuarios y la creación de prototipos suele ser muy variable.
Por este motivo, el enfoque adoptado por DORA consiste en medir el tiempo que transcurre desde que se confirma el código hasta su implementación, lo que le permite centrarse únicamente en las etapas que se encuentran dentro del ámbito de su proceso de CI/CD.
Un plazo de entrega prolongado significa que no se están presentando cambios de código a los usuarios con regularidad y, por lo tanto, no está disfrutando de las ventajas del feedback para perfeccionar lo que se está creando. Esto puede deberse a varios factores.
Un proceso de lanzamiento que implique pasos manuales, como un gran número de pruebas manuales, evaluaciones de riesgo o paneles de revisión de cambios, puede añadir días o semanas al proceso, socavando las ventajas de los lanzamientos frecuentes.
Mientras que la inversión en pruebas automatizadas se ocupará de lo primero, lo segundo requiere un compromiso con las partes interesadas para entender cómo se pueden satisfacer sus necesidades de manera más eficiente. Por otra parte, si los pasos automatizados son lentos o poco fiables, se pueden utilizar métricas de duración de la compilación para identificar las etapas que requieren más tiempo.
Frecuencia de implementación
La frecuencia de implementación registra el número de veces que utiliza su proceso de CI/CD para implementar a producción. La frecuencia de implementación fue seleccionada por DORA como un proxy para el tamaño de lotes, ya que una alta frecuencia de implementación implica menos cambios por implementación.
Implementar un pequeño número de cambios con frecuencia reduce el riesgo asociado al lanzamiento (porque hay menos variables que pueden combinarse para arrojar resultados inesperados), y proporciona feedback más pronto.
Una baja frecuencia de implementación puede significar que el proceso no está siendo alimentado con confirmaciones regulares, tal vez porque las tareas no se están desglosando, o puede ser el resultado de la agrupación de cambios en lanzamientos más grandes.
Cuando los cambios deben ser agrupados por motivos empresariales (por ejemplo, debido a las expectativas de los usuarios), la medición de la frecuencia de las implementaciones en los sitios de puesta en escena le permitirá supervisar el tamaño de los lotes y evaluar si está cosechando los beneficios de trabajar en pequeños incrementos.
Tasa de fallos por cambios
La tasa de fallos por cambios se refiere a la proporción de los cambios implementados en producción que dan lugar a un fallo, como una interrupción o un error que requiere una reversión o un hotfix. La ventaja de esta métrica es que sitúa las implementaciones fallidas en el contexto del volumen de cambios realizados.
Una baja tasa de fallos en los cambios debería darle confianza en su proceso; indica que las primeras etapas del proceso están haciendo su trabajo y detectando la mayoría de los defectos antes de que su código se implemente en producción.
Tiempo medio de recuperación
El tiempo medio de recuperación o resolución (MTTR) mide el tiempo que se tarda en solucionar un fallo de producción. El MTTR reconoce que, en un sistema complejo con muchas variables, algunos fallos en la producción son inevitables. En lugar de buscar la perfección (y, por tanto, ralentizar los lanzamientos y perder las ventajas de los lanzamientos frecuentes), es más importante responder a los problemas con rapidez.
Mantener un MTTR bajo requiere una supervisión proactiva de su sistema en producción para alertarle de los problemas a medida que surgen, y la capacidad de revertir los cambios o implementar una solución rápidamente a través del proceso.
Una métrica relacionada, el tiempo medio de detección (MTTD), mide el tiempo que transcurre entre la implementación de un cambio y la detección por parte de su sistema de supervisión de un problema introducido por ese cambio. Al comparar el MTTD y la duración de la compilación, puede determinar si a alguna de las dos áreas le vendría bien alguna inversión para reducir su MTTR.
Métricas operativas y de CI
Además de estas medidas de alto nivel, hay una serie de métricas operativas que puede utilizar para comprender mejor el rendimiento de su proceso e identificar las áreas en las que podría mejorarlo.
Cobertura de código
En un proceso de CI/CD, las pruebas automatizadas deberían proporcionar la mayor parte de su cobertura de pruebas, liberando a los ingenieros de control de calidad para que se centren en las pruebas exploratorias y en la definición de nuevos casos de prueba. La primera capa de pruebas automatizadas que se realice debe ser la de las pruebas de unidades, ya que son las más rápidas de ejecutar y proporcionan la información más inmediata.
La cobertura de código es una métrica proporcionada por la mayoría de los servidores de CI que calcula la proporción de su código que cubren las pruebas de unidades. Merece la pena controlar esta métrica para asegurarse de que mantiene una cobertura de pruebas adecuada a medida que escribe más código. Si su cobertura de código tiende a disminuir con el tiempo, es hora de invertir algún esfuerzo en esta primera línea de feedback.
Duración de la compilación
La duración de la compilación o el tiempo de compilación mide el tiempo que se tarda en completar las distintas etapas del proceso automatizado. Observar el tiempo invertido en cada etapa del proceso es útil para detectar los puntos débiles o los cuellos de botella que podrían estar ralentizando el tiempo total que se tarda en obtener el feedback de las pruebas o en implementar para los usuarios.
Tasa de superación de pruebas
La tasa de superación de pruebas es el porcentaje de casos de prueba que se han superado con éxito en una compilación determinada. Mientras tenga un nivel razonable de pruebas automatizadas, esta es una buena indicación de la calidad de cada compilación. Puede utilizar esta métrica para comprender la frecuencia con la que los cambios en el código dan lugar a pruebas fallidas.
Aunque es preferible detectar los fallos con las pruebas automatizadas que depender de las pruebas manuales o descubrir los problemas en producción, si un conjunto concreto de pruebas automatizadas falla con regularidad, podría merecer la pena examinar la causa raíz de esos fallos.
Tiempo de resolución de pruebas
El tiempo de resolución de pruebas es el tiempo que transcurre entre que una compilación informa de que una prueba ha fallado y la misma prueba se supera en una compilación posterior. Esta métrica le indica la rapidez con la que es capaz de responder a los problemas identificados en el proceso.
Un tiempo de resolución breve muestra que está utilizando su proceso de la mejor manera posible; al tratar los problemas tan pronto como surgen, puede trabajar más eficientemente (ya que los cambios están todavía frescos en su mente), y evita crear más funcionalidades sobre un código inestable.
Implementaciones fallidas
Implementaciones fallidas que dan lugar a un tiempo de inactividad no deseado, que obligan a revertir la implementación o que requieren el lanzamiento urgente de una solución. El recuento de implementaciones fallidas se utiliza para calcular la tasa de fallos por cambios (sobre la que ya hemos hablado anteriormente).
La supervisión de la proporción de fallos sobre el número total de implementaciones ayuda a medir su rendimiento con respecto a los acuerdos de nivel de servicio.
Sin embargo, hay que tener en cuenta que un objetivo de cero (o muy pocas) implementaciones fallidas no es necesariamente realista, y puede animar a los equipos a dar prioridad a la seguridad. Si se hace así, los plazos de entrega son más largos y las implementaciones más grandes, ya que los cambios se agrupan, lo que aumenta la probabilidad de que se produzcan fallos en la producción (puesto que se unen más variables) y hace que sean más difíciles de solucionar (ya que hay más cambios que revisar).
Recuento de defectos
A diferencia de los fallos, el recuento de defectos se refiere al número de tickets abiertos en su backlog clasificados como errores. También puede desglosarse por incidencias encontradas en pruebas o en fase de puesta en escena, y por incidencias encontradas en producción.
Al igual que la cobertura de código, la supervisión del número de defectos es útil para alertar de una tendencia general al alza, que puede indicar que los errores se están descontrolando. Sin embargo, tenga en cuenta que convertir esta métrica en un objetivo puede hacer que su equipo se centre más en clasificar los tickets que en solucionarlos.
Tamaño de la implementación
Como corolario de la frecuencia de implementación (véase más arriba), el tamaño de la implementación –medido por el número de puntos de historia incluidos en una compilación o lanzamiento– puede utilizarse para controlar el tamaño de los lotes dentro de un equipo concreto.
Mantener las implementaciones reducidas muestra que su equipo confirma con frecuencia, con todos los beneficios que ello conlleva. Sin embargo, como las estimaciones de las historias no son comparables entre los equipos de desarrollo, esta métrica no debería utilizarse para medir el tamaño total de la implementación.
Conclusión
Monitorizar estas métricas le permite comprender mejor el rendimiento de su proceso de CI/CD y si se encuentra en una tendencia ascendente o descendente.
Puede utilizar las métricas para identificar las áreas de su proceso que merecen mayor atención. Una vez que haya realizado un cambio, es una buena práctica seguir supervisando las métricas pertinentes para verificar si ha surtido el efecto deseado.
Sin embargo, aunque las métricas pueden proporcionar indicadores útiles de rendimiento, es importante leer las cifras en su contexto y considerar qué comportamientos podrían incentivarse al centrarse en una métrica concreta. Tenga en cuenta que el objetivo no son los números en sí, sino mantener su proceso rápido y fiable para poder seguir ofreciendo valor a los usuarios.