Developpez.com

Le Club des Développeurs et IT Pro

Pourquoi les builds échouent si souvent ?

Une étude de Google tente de répondre à la question

Le 2014-06-30 05:25:41, par Arsene Newman, Expert éminent sénior
Pourquoi les builds des logiciels échouent ? Voilà une question qui revient souvent chez les développeurs logiciels, quant aux réponses elles sont diverses même si une nouvelle étude révèle l’existence de certains points communs

Menée conjointement par Google, l’Université des sciences et des technologies de Hong Kong et l’Université du Nebraska, cette étude tente de répondre à trois questions : A quelle fréquence les builds échouent ? Pourquoi échouent-elles ? Et enfin combien de temps faut-il pour les fixer ?

Pour répondre à ces questions, un échantillon de 26 millions de builds effectuées par 18.000 ingénieurs de Google a été utilisé. Quant aux langages utilisés pour ces builds, il a été question du C++ et de Java.

L’étude s’est intéressée en particulier aux erreurs générées lors de la compilation des builds par le compilateur javac (pour Java) et le compilateur LLVM Clang (pour le C++), elle les a classés en 5 catégorie : dépendance, incompatibilité de type, syntaxique, sémantique et autre.
Les résultats de l’étude débouchent alors sur trois constats :

L’échec des builds n’est pas relatif à leur fréquence ou à l’expérience du développeur : alors que l’on pourrait penser que le développeur expérimenté est moins en proie aux échecs, l’étude démontre qu’il n’y a pas de corrélation entre l’expérience du développeur et le taux d’échec.

La majorité des erreurs sont des erreurs de dépendances : Dans le cas de Java pas moins de 65% des erreurs sont relatives à des dépendances, alors que pour le C++ ce taux avoisine les 53%. En tête de liste des erreurs récurrentes en C++: l’identifiant non déclaré et les variables de classe manquantes.

Le C++ génère plus d’erreurs que le Java, mais elles sont plus faciles à corriger en contrepartie : 38.4% et 28.5% voilà donc les taux d’échec respectifs dans le cas d’un projet C++ et Java. L’étude révèle aussi la récurrence des erreurs syntaxiques sous C++ comparé à Java, ce qui s’explique par l’utilisation plus fréquente des IDE sous Java, expliquant par la même occasion la différence entre les deux taux et la facilité de correction des erreurs sous C++ comparé à Java.

Au final, cette étude apporte certains éléments de réponse par rapport à l’échec des builds, mais il est difficile de généraliser ces résultats sur le développement logiciel d’une manière globale, d’autres études sont nécessaires pour appuyer ces résultats.

Source : Etude de Google

Et vous ?
Qu’en pensez-vous ?
Etes-vous d’accord avec les résultats de cette étude ? Pourquoi ?
  Discussion forum
17 commentaires
  • Marco46
    Expert éminent sénior
    Envoyé par pmithrandir
    Est-ce que l'on parle bien d'intégration continue ?

    Parce que si c'est le cas, je pense que vu la flanquée de test à exécuter avant chaque livraison sur un repository (svn ou git) alors que ca sera de nouveau testé automatiquement par le serveur... c'est normal que les gens oublient, voir fasse confiance à la machine derrière.
    Sur une petite équipe, ou avec des système comme git, le système fonctionne très bien avec des build qui échouent. Au pire, on redeploie la version de la veille ou la dernière version qui passe le build. rien de grave.
    Non c'est pas normal, ça veut dire que le dev ne sait pas utiliser ses tests.

    Pour moi c'est une erreur qui doit entrainer une sanction sans appel : l'achat de chocolatines pour l'ensemble de l'équipe le lendemain.

    Plus sérieusement, pousser du code niqué sur un repo ça veut dire pousser des bugs aux autres, ce qui peut facilement faire perdre des heures avant que ça ne soit détecté. Donc c'est pas anodin.
  • mmw01
    Membre du Club
    Envoyé par Arsene Newman


    Le C++ génère plus d’erreurs que le Java, mais elles sont plus faciles à corriger en contrepartie : 38.4% et 28.5% voilà donc les taux d’échec respectifs dans le cas d’un projet C++ et Java. L’étude révèle aussi la récurrence des erreurs syntaxiques sous C++ comparé à Java, ce qui s’explique par l’utilisation plus fréquente des IDE sous Java, expliquant par la même occasion la différence entre les deux taux et la facilité de correction des erreurs sous C++ comparé à Java.

    Au final, cette étude apporte certains éléments de réponse par rapport à l’échec des builds, mais il est difficile de généraliser ces résultats sur le développement logiciel d’une manière globale, d’autres études sont nécessaires pour appuyer ces résultats.

    Qu'est ce qu'ils veulent nous montrer avec cette étude ?
    si les builds échouent c'es pas justement pour ca qu'ils sont fait en premier pour déceler les erreurs !!
    car on aura beau verifié le code et les dépendances c'est à la compilation qu'on verra s'il y a erreur ou pas !!
  • Paul TOTH
    Expert éminent sénior
    Envoyé par mmw01
    Qu'est ce qu'ils veulent nous montrer avec cette étude ?
    si les builds échouent c'es pas justement pour ca qu'ils sont fait en premier pour déceler les erreurs !!
    car on aura beau verifié le code et les dépendances c'est à la compilation qu'on verra s'il y a erreur ou pas !!
    je suppose que l'étude porte sur le build d'un produit distribué sous forme de source. je prend les sources, je build, et hop ça ne marche pas.
  • spidetra
    Membre confirmé
    Envoyé par atha2
    C'est quoi un build en Java ?? Les compilations en temps réel fait pas l'IDE sont-elles prises en compte ?
    L'étude porte sur le système de build centralisé de google. Système de build propriétaire.
    Par exemple, Un build peut inclure 2858 targets dans 6 langages différents.

    Envoyé par atha2

    C'est moi qui ai un problème avec les statistiques ou il y a une incohérence ? Comment 53% des builds échoués en C++ liés à une dépendance manquante, peuvent ne pas être en tête ? Mauvaise traduction ?
    Il faut distinguer les 5 catégories : dépendance, incompatibilité de type, syntaxique, sémantique et autre
    Des types d'erreurs : l’identifiant non déclaré et les variables de classe manquantes.

    Identifiant non déclaré appartient à la catégorie : Dépendance.

    Envoyé par atha2

    Sinon il serait intéressant que savoir comment travail les développeurs C++ chez Google, avec un IDE comme Visual Studio (Complétion...) ? Dans le cas contraire, ça explique facilement la différence avec Java.
    Java : Eclipse & IDEA (90% ddes developpeurs java)
    C++ : Emacs ou Vi (80% des developpeurs C++)

    Envoyé par atha2

    Je vois mal comment on peut builder (génération jar, war...) avec des erreurs de syntaxe en Java...
    Il faut distinguer le build local dans son IDE, du build avec le système centralisé de Google.
    Avant chaque commit, un dvp doit s'assurer que son code build avec le système centralisé, et pas seulement en local.
  • 23JFK
    Membre expert
    Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?
  • atha2
    Membre éprouvé
    Envoyé par 23JFK
    Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?
    J'aaaaaaiiiiime
    Pour info, c'est au moins la 3ème fois que ça arrive. Perso j'ai carrément tout perdu (sauf le projet). J'ai désinstallé les plugins de la version précédente pour résoudre le conflit, mauvaise idée. Je me suis retrouvé sans exécutable . C'est un peu du foutage de gueule de la part de Google. Ils n'ont pas testé la MAJ avant de la publier ? J'aurais bien poussé un coup de gueule sur leur page Google + mais j'ai pas trouvé comment créer un nouveau poste
    Du coup je suis passé à Android Studio.
  • pmithrandir
    Expert éminent
    marco, il faudrait donc, pour que le boulot soit plus agréable, automatiser ce prebuild avant commit.(voir de tester qu'il a été fait, pas trop dur avec un checksum par exemple)

    Pour ma part, jee dirais que ca dépend de plusieurs facteurs :
    - la taille de l'équipe, on ne travaille pas de la même façon a 5 ou a 15.
    - Les exigences en terme de deploiement continu.

    Parce que ca ne me choque pas qu'une petite équipe a plusieurs mois de la release ne perde pas son temps a exécuter tous les tests quand jenkins le fera 10 minutes plus tard sur une machine mieux configuré. La perte de temps n'étant dailleur pas si grande en général.
  • Marco46
    Expert éminent sénior
    Oui il faut que chaque dev puisse builder l'application sur son poste. Et le temps de build + test doit être de l'ordre de 5/10 mins. Les TU ne coutent rien en temps d'exécution, si ton projet est vraiment énorme il faut le modulariser et faire gaffe aux tests d'intégrations et e2e c'est ça qui bouffe du temps.

    Parce que ca ne me choque pas qu'une petite équipe a plusieurs mois de la release ne perde pas son temps a exécuter tous les tests quand jenkins le fera 10 minutes plus tard sur une machine mieux configuré. La perte de temps n'étant dailleur pas si grande en général.
    Moi ça me choque. Parce que je pense que si tu fais la somme du temps perdu avec les régressions qui se dispatchent partout si chaque dev vérifie pas son taf avant de push comparée à la somme des builds locaux (tu lances ton build puis tu vas prendre ta pause café/toilettes) ben tu vas voir que le fait de pas être rigoureux sur ça fait perdre du temps.

    Et plus tu tardes à détecter les régressions plus elles sont longues à résoudre. Et puis ça contribue à une mauvaise ambiance de travail en +.
  • spidetra
    Membre confirmé
    Envoyé par mmw01
    Qu'est ce qu'ils veulent nous montrer avec cette étude ?
    Ils ne veulent rien nous prouver. Ils essaient de comprendre pourquoi et comment des builds échouent.
    26.6 M de builds en 6 mois pour 18.000 dvp.

    Pour Google, analyser et comprendre les raisons des échecs doit leur permettre de mettre en place des plans d'actions pour améliorer leurs process, mettre en place des outils, sensibiliser les dvps, etc...
  • spidetra
    Membre confirmé
    Envoyé par Paul TOTH
    je suppose que l'étude porte sur le build d'un produit distribué sous forme de source. je prend les sources, je build, et hop ça ne marche pas.
    Non, l'étude porte sur le système de build centralisé de Google.