Ne détestez-vous pas simplement quand quelque chose casse la construction de votre logiciel ? Les problèmes de construction créent un surcroît de travail non planifié. Ils semblent toujours se produire lorsque vous vous précipitez pour résoudre un autre problème. Souvent, la construction est interrompue par un facteur qui n'est pas lié à ce que vous faites en ce moment. Il peut donc être assez frustrant de devoir abandonner ce que vous faites, creuser ce qui a causé la rupture du build, réparer ce problème et redémarrer le build (en espérant que vous n'ayez qu'un seul problème à résoudre).
Je suis tombé sur cette question aujourd'hui, alors que je reconstruisais certains logiciels à code source ouvert. Il y a quelques mois, nous avons mis à jour notre copie d'OpenSSL à la version 1.0.0, mais nous n'avons pas reconstruit tous les paquets qui en dépendent. Il se trouve que lorsque je suis allé reconstruire le client subversion pour récupérer une correction de bogue, j'ai trouvé que la compilation subversion était cassée du fait qu'OpenSSL 1.0.0 introduisait des changements incompatibles. Il ne m'a pas fallu longtemps pour trouver le correctif, car ce problème avait été corrigé il y a des mois, et une simple recherche sur le web a permis de trouver à la fois le rapport de bogue et le correctif. Mais il était encore assez irritant de rencontrer ce problème alors que j'essayais juste de reconstruire le produit.
Je n'ai pas de suggestion brillante à faire ici. Mais j'ai une observation à faire, à savoir que le temps machine est maintenant abondant. Peut-être devrions-nous simplement reconstruire tous nos logiciels chaque nuit. Cela nous permettra d'attraper les problèmes de construction lorsque les questions sont encore fraîches dans l'esprit de chacun.
De plus, au cas où vous auriez des étapes manuelles dans votre processus de construction, décider de reconstruire fréquemment sera une bonne incitation à les éliminer. Les étapes manuelles sont une source commune d'erreurs.
Les testeurs de logiciels ont tendance à ne pas aimer reconstruire les logiciels une fois qu'ils les ont testés. Ils y voient une occasion d'introduire de nouveaux défauts. J'aime avoir suffisamment confiance dans mes outils de compilation (compilateurs, linkers, makefiles) pour pouvoir reconstruire à tout moment. Étant donné que nous travaillons dans des langages de haut niveau, nous devons avoir confiance dans nos outils de compilation. Mais il y a suffisamment de place pour les deux points de vue dans un processus de développement par étapes.
Si vous avez des suggestions sur la façon de gérer le développement de logiciels afin de minimiser les risques de rupture de la construction, ou de minimiser l'effort nécessaire pour corriger les problèmes de construction, veuillez ajouter vos commentaires à ce post.