Cómo reducir las compilaciones inestables (flaky builds) a 1/18

En GitHub definen como flaky build una compilación en la que, con el mismo código, en algunos casos falla y en otros pasa. Dicen que introdujeron automatización para que cada persona que escribió ese código resuelva el problema y no afecte a otras personas, logrando reducir las flaky builds a 1/18.

En el CI interno de GitHub rastrean las flaky builds, organizan las situaciones problemáticas y luego las asignan a la persona que se estima pudo haber causado ese problema.

• Al rastrear las flaky builds vieron que la frecuencia variaba, y las flaky builds que fallaban más de 100 veces representaban el 0.4% del total. Así que decidieron enfocarse en ese 0.4%.

• Cuando lo introdujeron en 2016, lo abordaron con los siguientes dos métodos.

  • Cuando termina una compilación, buscan compilaciones ejecutadas con el mismo commit y, si los resultados son distintos, la marcan como flaky build.

  • Si se reintenta dentro de la misma compilación y el resultado cambia, la marcan como flaky build.

• Con este método solo podían distinguir el 25% del total de las flaky builds.

Mejoras

• Usaron un método de 3 reejecuciones.

  1. Se reintenta en el mismo proceso. Estas flaky builds ocurren por aleatoriedad en el código o por condiciones de carrera.

  2. Se reintenta en el mismo proceso, pero después de que pasa un tiempo. Estas flaky builds ocurren cuando se hicieron suposiciones incorrectas sobre el tiempo.

  3. Se reintenta en un host completamente distinto. Estas flaky builds ocurren por dependencia del orden de las pruebas o por estado compartido.

Con este método pudieron detectar automáticamente el 90%.

Medición del impacto

Necesitaban una forma de cuantificar el impacto para definir prioridades.

Usan información como compilación, rama, autor y commit para asignar una puntuación de impacto según cuánto falla y cuánto afecta a otras ramas o desarrolladores.

Si supera cierta puntuación, crean un issue para que los desarrolladores puedan corregirlo y se lo asignan al desarrollador correspondiente.

[ganadist]

En mi caso, encontrábamos con frecuencia builds inestables en los unittest de Gradle, así que aplicamos las siguientes soluciones.

• Si usas el plugin https://plugins.gradle.org/plugin/org.gradle.test-retry, ayuda mucho para rastrear builds inestables en los unittest.

• Si usas https://docs.gradle.org/current/dsl/…, como se ejecuta en un proceso nuevo después de cierto tiempo, puede ayudar a mitigar los builds inestables.

• Si implementas Gradle Enterprise, puedes ver fácilmente la evolución de los builds inestables. https://gradle.com/blog/flaky-tests/