Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration
Este estudio empírico analiza 77 354 fallos de compilación de CI en siete proyectos de Apache para cuantificar el esfuerzo de desarrollo desperdiciado en fallos no relacionados y demuestra que los modelos de aprendizaje semi-supervisado de Positivo y No Etiquetado (PU), que utilizan características como la latencia de CI y los patrones de error, pueden predecir eficazmente dichos fallos no accionables para ayudar a los desarrolladores a priorizar sus esfuerzos de depuración.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que eres un chef trabajando en una cocina muy concurrida y caótica (este es el entorno de Integración Continua). Cada pocos minutos, llega un nuevo pedido (un envío de código), y la cocina comienza automáticamente a preparar una comida de prueba para ver si los nuevos ingredientes funcionan.
A veces, la comida de prueba se quema o sabe terrible. Por lo general, esto significa que el chef que acaba de añadir los nuevos ingredientes cometió un error. Pero a veces, la alarma de incendios suena porque el chef anterior dejó la estufa encendida, o el horno se rompió, o alguien más dejó caer una bandeja en la habitación contigua. Esto es lo que el artículo llama un "Fallo de Construcción No Relacionado".
El problema es que el chef que acaba de añadir los nuevos ingredientes no sabe por qué falló la comida. Pasan horas (el artículo indica una mediana de 4 horas) revisando frenéticamente sus propias especias y cuchillos, tratando de demostrar: "¡No fui yo!". Esto desperdicia mucho tiempo y causa estrés.
Lo que hicieron los investigadores
Los autores (un equipo de investigadores) decidieron investigar este caos en la cocina. Examinaron 77,354 "comidas quemadas" (fallos de construcción) de 7 grandes proyectos de software de código abierto (como Apache Hadoop y HBase).
- El trabajo de detective: Leyeron manualmente miles de comentarios dejados por los desarrolladores tras un fallo. Buscaron frases como "esto no está relacionado con mi cambio" o "no relacionado". Encontraron aproximadamente 10,300 casos donde los desarrolladores dijeron explícitamente: "Este fallo no fue culpa mía".
- La entrevista: Seleccionaron una muestra más pequeña y representativa de 371 de estos casos de "no fue culpa mía" y los analizaron como un detective analiza una escena del crimen. Preguntaron: ¿Por qué dijeron los desarrolladores que esto no fue culpa suya?
- Los hallazgos: Las razones más comunes fueron:
- Pruebas no relacionadas: La prueba que falló en realidad estaba verificando algo de una parte diferente de la cocina, no del nuevo ingrediente.
- Interferencia externa: Algo fuera de la cocina cambió (como un proveedor entregando harina de mala calidad a todos).
- No reproducible: El fuego ocurrió una vez, pero cuando intentaron preparar la comida de nuevo, todo estuvo bien (quizás una sobretensión eléctrica aleatoria).
- El grupo "No especificado": Una gran parte (35%) de las veces, los desarrolladores simplemente dijeron "No fui yo" sin explicar por qué.
- Los hallazgos: Las razones más comunes fueron:
La solución: Un "Asistente Inteligente"
Dado que los desarrolladores no siempre pueden explicar por qué un fallo no está relacionado de inmediato, los investigadores construyeron un Asistente Inteligente (un modelo de aprendizaje automático) para adivinar por ellos.
Utilizaron una técnica especial llamada Aprendizaje PU (Aprendizaje Positivo-No Etiquetado).
- La analogía: Imagina que estás tratando de enseñarle a un perro a encontrar un tipo específico de pelota. Tienes algunas pelotas que sabes que son del tipo correcto (los ejemplos Positivos). Pero tienes una pila enorme de pelotas mezcladas donde no sabes cuáles son del tipo correcto y cuáles no (la pila No Etiquetada). No puedes simplemente decir "todo lo demás es una pelota incorrecta" porque algunas de ellas podrían ser en realidad del tipo correcto, simplemente aún no las has revisado.
- Cómo funcionó: Los investigadores alimentaron a su modelo con los "fallos no relacionados conocidos" y la "pila desconocida". El modelo aprendió a detectar patrones que sugieren que un fallo probablemente no está relacionado, incluso sin una etiqueta clara.
¿Qué tan bueno fue el asistente?
El modelo fue probado en los mismos 7 proyectos.
- Fue muy bueno en precisión (cuando decía "Esto no es culpa tuya", por lo general tenía razón, entre el 70% y el 88% de las veces).
- Fue bueno en exhaustividad (encontró la mayoría de los fallos no relacionados, aunque se le escaparon algunos).
- Superó significativamente a la adivinanza aleatoria o a reglas simples.
Las "pistas" que usó el modelo
Los investigadores encontraron tres pistas principales que ayudaron al modelo a decidir si un fallo no estaba relacionado:
- El intervalo de tiempo (Latencia de CI): Si un desarrollador envió código y esperó mucho tiempo antes de activar la construcción, es más probable que alguien más haya roto la cocina en el ínterin.
- El error "Dejá vu": Si el mensaje de error se ve exactamente igual que uno que ocurrió recientemente, probablemente sea una repetición de un problema antiguo, no uno nuevo causado por el chef actual.
- La conversación: Si hay muchos comentarios en el problema antes de que ocurriera el fallo, sugiere que el problema es complejo y probablemente involucra el trabajo de otras personas, no solo el envío actual.
La conclusión
El artículo concluye que, al usar este "Asistente Inteligente", los desarrolladores pueden obtener una pista rápida: "Hay una alta probabilidad de que este fallo no sea culpa tuya".
Esto no significa que puedan ignorar el problema, pero les dice: "No gastes 4 horas revisando tu propio código. Quizás revises el horno o le preguntes al otro chef". Esto les ayuda a dejar de perder tiempo en falsas alarmas y volver a cocinar (programar) más rápido.
Nota importante: El artículo se centra exclusivamente en la identificación de estos fallos en proyectos de software. No afirma que este método funcione para diagnósticos médicos, trading financiero o cualquier otro campo fuera del desarrollo de software. Es estrictamente una herramienta para que los equipos de software gestionen su propio caos de "cocina".
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.