Réduire d’un facteur 18 les builds instables (`flaky builds`)

GitHub définit comme flaky build un build qui, avec le même code, échoue dans certains cas et réussit dans d’autres. L’entreprise explique avoir réduit ces builds instables d’un facteur 18 en introduisant de l’automatisation, afin que chaque problème flaky soit résolu par la personne qui a écrit le code concerné et n’impacte pas les autres.

Dans la CI interne de GitHub, les builds instables sont suivis, les situations problématiques sont documentées, puis le problème est attribué à la personne présumée l’avoir introduit.

• En suivant les flaky builds, GitHub a constaté que leur fréquence variait, et que ceux qui échouaient plus de 100 fois ne représentaient que 0,4 % du total. L’équipe a donc décidé de se concentrer sur ces 0,4 %.

• Lors de l’introduction de cette approche en 2016, deux méthodes ont été utilisées.

  • Une fois le build terminé, rechercher les builds exécutés sur le même commit et, si les résultats diffèrent, les marquer comme flaky builds

  • Si une nouvelle tentative sur le même build produit un résultat différent, le marquer comme flaky build

• Cette méthode ne permettait d’identifier que 25 % de l’ensemble des flaky builds.

Amélioration

• Utilisation d’une méthode de réexécution en 3 étapes

  1. Réessayer dans le même processus. Ce type de flaky build est causé par le caractère non déterministe du code ou par des race conditions.

  2. Réessayer plus tard, mais toujours dans le même processus. Ce type de flaky build survient lorsqu’on fait de mauvaises hypothèses liées au temps.

  3. Réessayer sur un hôte complètement différent. Ce type de flaky build est causé par une dépendance à l’ordre des tests ou par un état partagé.

Grâce à cette méthode, il est devenu possible de détecter automatiquement 90 % des cas.

Mesure de l’impact

Pour définir les priorités, il fallait une méthode permettant de quantifier l’impact.

En utilisant des informations comme le build, la branche, l’auteur ou le commit, GitHub attribue un score d’impact pour mesurer la fréquence des échecs et leur effet sur d’autres branches ou développeurs.

Lorsqu’un certain score est dépassé, une issue est créée et attribuée au développeur afin qu’il puisse corriger le problème.

[ganadist]

Dans mon cas, des flaky builds étaient souvent détectés dans les tests unitaires de Gradle, j’avais donc appliqué les solutions ci-dessous.

• Utiliser le plugin https://plugins.gradle.org/plugin/org.gradle.test-retry aide beaucoup à suivre les flaky builds sur les tests unitaires.

• Utiliser https://docs.gradle.org/current/dsl/… permet d’exécuter les tests dans un nouveau processus après un certain temps, ce qui peut atténuer les flaky builds.

• Adopter Gradle Enterprise permet de visualiser facilement l’évolution des flaky builds. https://gradle.com/blog/flaky-tests/