Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

Imaginez que vous faites partie d'une équipe de construction massive et mondiale élevant une ville de nuage géante et complexe appelée OpenStack. Cette ville n'est pas construite par une seule personne ; elle est bâtie par des milliers d'ouvriers (développeurs) travaillant sur des centaines de quartiers différents (projets) comme Cinder, Glance et Nova. Pour s'assurer que la ville ne s'effondre pas, chaque fois qu'un ouvrier ajoute une nouvelle brique ou modifie un tuyau, il exécute une série de « contrôles de sécurité » automatisés (tests).

Idéalement, ces contrôles de sécurité devraient fonctionner comme un feu de circulation parfait : Vert signifie « Allez, le changement est sûr », et Rouge signifie « Stop, il y a un problème ».

Mais parfois, le feu de circulation clignote. Il passe au Rouge sans raison valable, puis au Vert lorsque vous vérifiez à nouveau, puis au Rouge à nouveau. Dans le monde du logiciel, cela s'appelle l'« Instabilité » (ou « Flakiness »). C'est comme un test qui est simplement « lunatique » — il ne sait pas s'il réussit ou échoue, même si rien n'a changé dans le code.

Ce papier est une histoire de détective sur la façon dont ce comportement « lunatique » se propage à travers toute la ville d'OpenStack, et pas seulement dans un seul quartier.

Les Deux Grands Problèmes Qu'ils Ont Découverts

Les chercheurs ont découvert deux façons spécifiques dont ce comportement « lunatique » cause des ennuis :

1. Le Bug « Contagieux » (Instabilité Inter-Quartiers)
Imaginez un contrôle de sécurité spécifique (un test) censé vérifier si une serrure de porte fonctionne. Dans cette ville, ce même test de serrure est utilisé dans le quartier Cinder, le quartier Glance et le quartier Nova.

• Le Problème : Le test de serrure est « lunatique ». Il échoue de manière aléatoire dans ces trois quartiers.
• L'Impact : Parce que les quartiers partagent ce seul test, un seul test défaillant arrête les progrès à plusieurs endroits à la fois. Les chercheurs ont découvert que 55 % de tous les quartiers d'OpenStack sont touchés par ces bugs contagieux. C'est comme une seule pomme pourrie qui gâte tout le tonneau, mais la pomme est en fait un test que tout le monde utilise.

2. Le Bug « Sélectif » (Instabilité Incohérente)
Maintenant, imaginez que ce même test de serrure est utilisé dans le quartier Cinder et le quartier Nova.

• Le Problème : Dans Cinder, le test est parfaitement fiable (toujours Vert). Mais dans Nova, exactement le même test est « lunatique » (clignotant entre Rouge et Vert).
• L'Impact : C'est déroutant ! Cela signifie que le test lui-même n'est pas cassé ; quelque chose dans l'environnement de Nova cause les ennuis. C'est comme une voiture qui démarre parfaitement dans votre allée mais qui tousse à chaque fois que vous essayez de la démarrer chez un ami. Les chercheurs ont trouvé plus de 1 100 de ces bugs « sélectifs ».

La Grande Surprise : Même les Tests « Unitaires » Tombent Malades

Habituellement, les développeurs considèrent les Tests Unitaire comme les « microscopes » du monde du logiciel. Ils examinent de minuscules morceaux de code isolés (comme une seule fonction) dans le vide. Ils sont censés être les tests les plus stables et prévisibles car ils ne parlent pas au monde extérieur.

La Découverte Choc du Papier :
Les chercheurs ont découvert que 70 % de ces tests « microscopes » sont en fait impliqués dans les bugs « Contagieux ».

• Analogie : C'est comme découvrir que les minuscules vis isolées qui maintiennent votre grille-pain ensemble sont les mêmes vis qui provoquent un court-circuit dans tout le système électrique de la cuisine. Nous pensions que ces petits tests étaient sûrs et isolés, mais dans un écosystème géant, ils sont profondément connectés et peuvent propager l'instabilité partout.

Pourquoi Cela Arrive-t-il ? (Les Causes)

L'équipe a creusé dans les journaux pour savoir pourquoi les tests se comportaient mal dans certains endroits mais pas dans d'autres. Ils ont trouvé trois principaux coupables :

1. La « Condition de Course » (Le Tueur à 89 %) : C'est la cause la plus courante. Imaginez deux ouvriers essayant de saisir le même outil à la milliseconde exacte. Parfois, l'Ouvrier A l'obtient ; parfois, c'est l'Ouvrier B. Si le test essaie de saisir une ressource (comme un serveur ou un fichier) qui est déjà utilisée par autre chose, il échoue. S'il l'obtient, il réussit. Cette aléatoire est appelée une « condition de course ».
2. Configurations Incompatibles : C'est comme essayer de faire un gâteau en utilisant une recette d'un pays mais des ingrédients d'un autre. Le test attend une configuration spécifique (comme une version spécifique d'une bibliothèque ou une vitesse de serveur spécifique), mais l'environnement ne correspond pas.
3. Problèmes de Dépendances : Un quartier peut avoir mis à jour son « réseau électrique » (une bibliothèque logicielle), tandis que la ville voisine ne l'a pas fait. Le test fonctionne dans la ville mise à jour mais échoue dans l'ancienne.

Le Coût de l'Approche « Attendre et Voir »

Lorsqu'un test échoue, la réaction standard dans OpenStack est de dire : « Oh, ce doit être un bug. Refaisons-le simplement (recheck) et attendons. »

• Le Coût : Les chercheurs ont calculé que cette habitude de « retester et attendre » a gaspillé 1 156 jours de temps de calcul et d'argent.
• L'Analogie : C'est comme un policier de la circulation voyant un feu rouge, supposant que le capteur est cassé, faisant passer les voitures, puis vérifiant à nouveau, puis les faisant passer à nouveau. Cela gaspille du carburant (ressources informatiques) et retarde le trajet de tout le monde (révisions de code).

Que Disent les Ouvriers ? (Retour des Développeurs)

Les chercheurs ont demandé aux vrais constructeurs (développeurs) à ce sujet.

• La Frustration : De nombreux développeurs se sentent impuissants. Ils disent : « Je suis nouveau, je ne sais pas à qui demander, alors je continue simplement à appuyer sur « recheck » jusqu'à ce que cela réussisse. »
• La Réalité : Ils admettent que résoudre ces problèmes est difficile car cela nécessite de parler à plusieurs équipes. Si un test échoue dans Nova à cause d'un problème dans Cinder, le développeur de Nova doit attendre que l'équipe de Cinder le répare.
• Le Déficit d'Outils : Ils ont mentionné que bien que des outils existent pour aider, ils tombent souvent en panne ou sont abandonnés car personne n'a le temps de les maintenir. Ils ont besoin d'un « mécanicien » dédié pour le système d'intégration continue, et pas seulement de bénévoles qui le font sur le côté.

La Conclusion

Le papier conclut que dans un écosystème logiciel géant et connecté, on ne peut pas traiter les tests comme des îles isolées.

• Pour les Développeurs : Arrêtez simplement de « retester » et d'attendre. Enquêtez sur pourquoi un test a échoué, même si cela semble sans rapport avec votre code.
• Pour les Chefs d'Équipe : Vous devez standardiser la façon dont les tests sont exécutés dans tous les quartiers. Si une ville utilise un outil spécifique, tout le monde devrait en utiliser un. Vous devez également centraliser le suivi de ces bugs afin que tout le monde sache quelles « vis » sont desserrées.
• Pour l'Avenir : Nous avons besoin de meilleurs outils pour nous dire automatiquement pourquoi un test est instable (par exemple : « Il a échoué parce que le serveur était hors ligne », et pas seulement « Il a échoué »).

En bref, le papier soutient que pour maintenir la ville d'OpenStack en bon fonctionnement, nous devons cesser de traiter les échecs de test comme une mauvaise chance aléatoire et commencer à les traiter comme un problème de coordination systémique qui affecte toute la ville.