Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi les builds échouent si souvent ?
Une étude de Google tente de répondre à la question

Le , par Arsene Newman

0PARTAGES

2  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 02/07/2014 à 10:14
Citation Envoyé par pmithrandir Voir le message
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.
2  0 
Avatar de mmw01
Nouveau membre du Club https://www.developpez.com
Le 30/06/2014 à 21:17
Citation Envoyé par Arsene Newman Voir le message


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 !!
1  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 30/06/2014 à 21:37
Citation Envoyé par mmw01 Voir le message
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.
1  0 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 30/06/2014 à 23:39
Citation Envoyé par atha2 Voir le message
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.

Citation Envoyé par atha2 Voir le message

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.

Citation Envoyé par atha2 Voir le message

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++)

Citation Envoyé par atha2 Voir le message

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.
1  0 
Avatar de 23JFK
Membre chevronné https://www.developpez.com
Le 01/07/2014 à 17:20
Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?
1  0 
Avatar de atha2
Membre éprouvé https://www.developpez.com
Le 01/07/2014 à 21:30
Citation Envoyé par 23JFK Voir le message
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.
1  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 02/07/2014 à 16:57
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.
1  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 03/07/2014 à 16:18
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 +.
1  0 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 30/06/2014 à 23:44
Citation Envoyé par mmw01 Voir le message
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...
1  1 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 30/06/2014 à 23:44
Citation Envoyé par Paul TOTH Voir le message
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.
0  0