IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Pourquoi les builds échouent si souvent ?

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Pourquoi les builds échouent si souvent ?
    Pourquoi les builds échouent si souvent ?
    Une étude de Google tente de répondre à la question

    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 ?

  2. #2
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Janvier 2007
    Messages : 697
    Points : 1 241
    Points
    1 241
    Par défaut
    C'est quoi un build en Java ?? Les compilations en temps réel fait pas l'IDE sont-elles prises en compte ?
    Citation Envoyé par Arsene Newman Voir le message
    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.
    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 ?
    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.
    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.
    Je vois mal comment on peut builder (génération jar, war...) avec des erreurs de syntaxe en Java...
    Sinon dire que les erreurs sont plus faciles à résoudre en C++ qu'en Java, en se basant sur les statistiques, oui on peut dire ça. Mais une fois enlevées, les erreurs triviales (variables non déclarées, erreurs de syntaxe...), je pense que c'est juste n'importe quoi

    En fait, je ne vois pas l’intérêt de comparer Java et C++; les outils de développement ne sont pas les mêmes (pas d'IDE). Par contre savoir qu'en général, les builds échoue plus à cause d'un dépendance manquante en Java et à cause d'un problème de syntaxe en C++ (pris séparément), peut donner une indication sur les outils à mettre en place dans ces 2 langages pour gagner du temps.
    Pour résumer : en java, la syntaxe est vérifiée par l'IDE et les problèmes de dépendances manquantes sont généralement liés à une différence entre l'environnement de développement (JRE/JVM/etc fourni par l'IDE, différent de celui ciblé) et celui de production. En C++, la syntaxe n'est pas vérifiée automatiquement avant la compilation

  3. #3
    Membre du Club

    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2009
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2009
    Messages : 22
    Points : 40
    Points
    40
    Par défaut
    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 !!

  4. #4
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  5. #5
    Membre confirmé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 298
    Points : 484
    Points
    484
    Par défaut
    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.

  6. #6
    Membre confirmé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 298
    Points : 484
    Points
    484
    Par défaut
    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...

  7. #7
    Membre confirmé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 298
    Points : 484
    Points
    484
    Par défaut
    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.

  8. #8
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    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.

  9. #9
    Membre expert
    Profil pro
    undef
    Inscrit en
    Février 2013
    Messages
    956
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : Février 2013
    Messages : 956
    Points : 3 521
    Points
    3 521
    Par défaut
    Ceci est-il censé expliquer le total fuck-up que fiche l'update r23 dans eclipse-adt (pour android) ?

  10. #10
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Janvier 2007
    Messages : 697
    Points : 1 241
    Points
    1 241
    Par défaut
    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.

  11. #11
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  12. #12
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Ils parlent ici d'environ 5.4 builds par jour de dev...

    Soit la règle chez Google est de commiter plus vite que son ombre, surtout sans tester, soit ils ont pris en compte tous les "make" effectués à la main par les dev sur leur poste avant de commiter.

    Dans le premier cas, c'est inquiétant.
    Dans le second cas, cela devrait être précisé dans l'étude, car il est évident que cela va plus vite de taper "make" et de voir que le compilo gueule parce qu'il y écrit "toot" au lieu de "toto" plutôt que de relire toute la fonction pour vérifier qu'il n'y a pas de faute de frappe.

    Dans les deux cas, je ne comprends pas où ils veulent en venir, ni pourquoi ils ont fait un papier là-dessus.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  13. #13
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Dans le premier cas, c'est inquiétant.

    [...]

    Dans les deux cas, je ne comprends pas où ils veulent en venir, ni pourquoi ils ont fait un papier là-dessus.
    Ben non c'est pas inquiétant au contraire. Le but du jeu c'est d'avoir le moins de divergences possible entre le code de prod et celui en cours dev. A la moindre modification tu déploies.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  14. #14
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Ben non c'est pas inquiétant au contraire. Le but du jeu c'est d'avoir le moins de divergences possible entre le code de prod et celui en cours dev. A la moindre modification tu déploies.
    La première erreur, en nombre, en C++, ce sont des variables qui n'existent pas. Donc probablement des erreurs de frappe ou bien du nouveau code qui utilise des variables qui n'ont pas été déclarées.
    Commiter du code sans savoir s'il compile, c'est une ânerie, et ce que tu sois chez Google ou pas.

    Alors oui, ils ont sûrement des systèmes de pre-build, qui t'envoient un mail pour te dire que ton commit est pourri, et que ligne 543 tu utilises une variable marco46, et que tu voulais probablement utiliser Marco46.
    Il n'empêche que c'est un truc que tu peux faire en local, au moment où tu compiles, c'est à dire au moment où tu arrêtes de faire le code. Ainsi, tu économises un changement de contexte pour chaque erreur de compilation.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  15. #15
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    La première erreur, en nombre, en C++, ce sont des variables qui n'existent pas. Donc probablement des erreurs de frappe ou bien du nouveau code qui utilise des variables qui n'ont pas été déclarées.
    Commiter du code sans savoir s'il compile, c'est une ânerie, et ce que tu sois chez Google ou pas.

    Alors oui, ils ont sûrement des systèmes de pre-build, qui t'envoient un mail pour te dire que ton commit est pourri, et que ligne 543 tu utilises une variable marco46, et que tu voulais probablement utiliser Marco46.
    Il n'empêche que c'est un truc que tu peux faire en local, au moment où tu compiles, c'est à dire au moment où tu arrêtes de faire le code. Ainsi, tu économises un changement de contexte pour chaque erreur de compilation.
    Ce que j'appelle le build c'est le fait de passer du code source au produit fini en une seule action (script, ou autre).

    Le build doit être faisable en local.
    Le build doit obligatoirement couvrir les tests (unitaires, intégration et e2e).

    Donc ton build c'est schématiquement :
    1- Compilation
    2- Exécution des tests
    3- Déploiement
    4- Exécution des tests e2e

    Et là tu peux pousser sur ta base de source. Et en sécurité tu as ton serveur d'intégration continue qui continue de builder ton code en boucle dans un environnement plus proche de la prod que celui de dev, avec des outils d'analyse de code etc ...

    Donc au final l'erreur dont tu parles, le dev doit la voir immédiatement, et ce type d'erreur ne doit pas contaminer la base de source.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  16. #16
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Donc au final l'erreur dont tu parles, le dev doit la voir immédiatement, et ce type d'erreur ne doit pas contaminer la base de source.
    Nous sommes d'accord. Mais là, je parle de l'étude de Google : cette erreur est la plus fréquente lors des builds du code C++ disent-ils.

    Et moi, ce que je leur répond, c'est que soit ils considèrent comme build le moindre "make" ou équivalent fait en local sur le PC du développeur, et leur papier ne vaut pas grand chose, soit ils considèrent des vrais builds (comme tu les décris), et dans ce cas il est extrèmement inquiétant que ce genre d'erreurs apparaisse.

    Et c'est pour ça que je dis que dans les deux cas, le papier ne vaut pas grand chose en l'état.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  17. #17
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    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.

  18. #18
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    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 +.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

Discussions similaires

  1. Pourquoi les projets IT échouent si souvent ?
    Par Arsene Newman dans le forum Actualités
    Réponses: 39
    Dernier message: 22/04/2014, 14h25
  2. [Processeur] Pourquoi les moteurs 3d sont souvent limité par le cpu
    Par Fifou625 dans le forum Composants
    Réponses: 1
    Dernier message: 04/08/2011, 19h10
  3. [Hudson] Stoppe le build si les tests échouent
    Par romaintaz dans le forum Intégration Continue
    Réponses: 5
    Dernier message: 30/04/2008, 12h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo