[ez-toc]<\/p>\n
<\/p>\n
Lo que no se mide no se puede mejorar. Esta m\u00e1xima nos invita a disponer de una serie de m\u00e9tricas que nos ayuden a evaluar la calidad de nuestro proceso DevOps<\/a><\/strong>.<\/p>\n El objetivo principal de la pr\u00e1ctica DevOps<\/a> es agilizar el ciclo de vida del software<\/a>, asegurando la calidad en cada uno de los pasos y partiendo de la automatizaci\u00f3n y la monitorizaci\u00f3n<\/strong> como herramientas fundamentales para conseguirlo. Por ello, las m\u00e9tricas que proponemos desde MTP y que mostramos a continuaci\u00f3n se centran en ese objetivo, manteniendo tambi\u00e9n el foco en la calidad, ya que tampoco hay que olvidar que lo que se desea no es producir mal software a gran velocidad:<\/p>\n Por medio de esta m\u00e9trica podremos conocer en todo momento si los equipos de desarrollo est\u00e1n contribuyendo a la trazabilidad del c\u00f3digo, un aspecto fundamental.<\/p>\n Aunque no hay que llevar al extremo la cobertura de c\u00f3digo por test unitario, contar con un nivel adecuado ayuda a prevenir problemas en etapas posteriores.<\/p>\n Si una build, con independencia del motivo, no se completa correctamente, se pierde un tiempo valioso que repercutir\u00e1 en el resto del proceso de construcci\u00f3n del software.<\/p>\n Ya sea por indisponibilidad de entornos, por fallos en la configuraci\u00f3n o por defectos en los tests postdespliegue, conviene llevar traza de la cantidad de despliegues que no se han completado con \u00e9xito.<\/p>\n Esta m\u00e9trica nos ayudar\u00e1 a identificar procedimientos que no est\u00e9n del todo maduros, por ejemplo, pasos que a\u00fan no est\u00e9n automatizados o que requieran de revisi\u00f3n manual.<\/p>\n Uno de los objetivos debe ser hacer despliegues peque\u00f1os y frecuentes. Esta m\u00e9trica nos ayudar\u00e1 a saber si estamos acerc\u00e1ndonos o alej\u00e1ndonos de este objetivo.<\/p>\n Los tests autom\u00e1ticos son fundamentales en un entorno DevOps. Un despliegue puede interrumpirse por errores en los tests autom\u00e1ticos. Relacionar esta m\u00e9trica con otras, como el n\u00famero de defectos encontrados por entorno, puede ayudar a saber si los tests autom\u00e1ticos construidos son o no suficientes.<\/p>\n Ya sea por fallos detectados gracias a tests autom\u00e1ticos o a tests de usuario, es una m\u00e9trica que deber\u00eda tender a cero con el tiempo. Es un indicador de la madurez de todo el proceso.<\/p>\n Tanto en entornos intermedios como en entornos productivos, una indisponibilidad es un problema grave. Evidentemente, el problema es mayor si un entorno de producci\u00f3n deja de estar disponible. Por ello, podr\u00eda tener sentido dividir esta m\u00e9trica por tipo de entorno.<\/p>\n La rapidez con la que se reaccione para volver a dar servicio es clave para no interrumpir el ciclo de vida y para no da\u00f1ar la imagen de cara al cliente, adem\u00e1s de limitar una potencial p\u00e9rdida de ingresos.<\/p>\n Un defecto ser\u00e1 m\u00e1s costoso de corregir cuanto m\u00e1s tarde se detecte en el ciclo de vida. El objetivo es que esta m\u00e9trica tienda a cero. Como mencion\u00e1bamos anteriormente, si no vemos disminuido este valor con el tiempo, convendr\u00eda ajustar las bater\u00edas de test de todo tipo aplicadas al software.<\/p>\n Cada defecto que se da en un entorno productivo supone un coste en t\u00e9rminos de deterioro de imagen, potencial p\u00e9rdida de ingresos o corrupci\u00f3n de datos, por poner s\u00f3lo algunos ejemplos. El tiempo de resoluci\u00f3n debe ser m\u00ednimo para mantener estas consecuencias dentro de lo admisible.<\/p>\n Tiempo medio transcurrido entre el registro de un ticket y la puesta en producci\u00f3n de la funcionalidad asociada. Nos ayuda a medir el tiempo de respuesta de todo el engranaje DevOps.<\/p>\n Todas estas m\u00e9tricas<\/strong> son una ayuda a la hora de tomar decisiones, pero tambi\u00e9n para conocer si los cambios aplicados van o no en el buen camino.<\/p>\n Por Francisco M. Lozano Sanju\u00e1n<\/p>\n Consultor Senior Calidad de C\u00f3digo<\/strong><\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" [ez-toc] Lo que no se mide no se puede mejorar. Esta m\u00e1xima nos invita a disponer de una serie de m\u00e9tricas que nos ayuden a evaluar la calidad de nuestro proceso DevOps. El objetivo principal de la pr\u00e1ctica DevOps es agilizar el ciclo de vida del software, asegurando la calidad en cada uno de […]<\/p>\n","protected":false},"author":9,"featured_media":16990,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[204],"tags":[149],"class_list":["post-16988","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-archivo","tag-devops"],"acf":[],"yoast_head":"\nN\u00famero de commits asociados correctamente a un ticket.<\/strong><\/h2>\n
Porcentaje de c\u00f3digo cubierto por test unitario. <\/strong><\/h2>\n
Ratio de construcciones fallidas<\/strong>.<\/h2>\n
Ratio de despliegues fallidos.<\/strong><\/h2>\n
Tiempo medio de despliegue.<\/strong><\/h2>\n
Frecuencia de despliegue.<\/strong><\/h2>\n
Porcentaje de \u00e9xito en tests autom\u00e1ticos<\/strong>.<\/h2>\n
Defectos encontrados en entornos de integraci\u00f3n y UAT.<\/strong><\/h2>\n
Ratio de indisponibilidad.<\/strong><\/h2>\n
Tiempo medio para salir de indisponibilidad.<\/strong><\/h2>\n
Defectos encontrados en entorno productivo.<\/strong><\/h2>\n
Tiempo medio de resoluci\u00f3n de defectos en entorno productivo<\/strong>.<\/h2>\n
\u201cLead time\u201d de un cambio.<\/strong><\/h2>\n