Séparez les versions “debug” et “release”?

Je pense qu’il est préférable de publier la version du logiciel que vos développeurs ont réellement testée; J’ai donc tendance à supprimer la cible ‘debug’ du projet / makefile, de sorte qu’il n’y ait qu’une seule version pouvant être générée (et testée, déboguée et publiée).

Pour une raison similaire, je n’utilise pas d’assertions (voir également Les assertions sont-elles toujours mauvaises? …).

Une personne a soutenu que la raison de la version “debug” est qu’il est plus facile de déboguer: mais je pense que vous pourriez éventuellement vouloir prendre en charge et déboguer ce que vous avez publié. vous pouvez, si nécessaire, déboguer … cela peut signifier activer les symboles de débogage et désactiver certaines optimisations, même dans la version “release“.

Quelqu’un d’autre a dit que “c’est une si mauvaise idée”; c’est une politique que j’ai évoluée il y a quelques années, ayant été brûlée par:

  • Certains développeurs testent leur débogage mais ne publient pas de versions
  • Certains développeurs écrivent des bogues qui apparaissent uniquement dans la version de publication
  • La société publie la version finale après des tests inadéquats (est-ce toujours tout à fait suffisant?)
  • Être appelé à déboguer la version de publication

Depuis lors, j’ai vu plus d’une autre boutique de développement suivre cette pratique (c.-à-d. Ne pas avoir de versions séparées de débogage et de publication).

Quelle est votre politique?

Cela pourrait être mineur, mais cela ajoute à ce que d’autres ont dit ici. L’un des avantages des versions de test QA réside dans le fait qu’au fil du temps, les fonctionnalités intégrées de débogage et de journalisation de votre logiciel évolueront grâce aux besoins des développeurs qui doivent déterminer pourquoi les choses ne se passent pas correctement.

Plus les développeurs ont besoin de déboguer les versions de publication, meilleurs seront les outils à utiliser lorsque les clients auront des problèmes. Bien entendu, les développeurs n’ont aucune raison de travailler sur les builds de versions dans le cadre du cycle de développement.

En outre, je ne connais aucun éditeur de logiciels disposant de cycles suffisamment longs pour assurer le passage du QA de la mise au point au lancement des versions à mi-parcours de la période de test d’une version. Avoir à faire un cycle complet d’AQ est quelque chose qui arrive trop rarement.

Avoir des versions séparées de débogage et de publication est une bonne idée, car cela facilite le développement.

Mais les versions de débogage ne doivent être que pour le développement, pas pour les tests. Vous testez les versions de publication uniquement. Et vous n’utilisez pas de développeurs pour tester ces versions, vous utilisez des testeurs.

C’est une politique simple qui donne le meilleur des deux mondes, IMO.

Edit: En réponse à un commentaire, je pense qu’il est évident que les versions de débogage et de publication (peuvent) génèrent un code différent. Pensez “-DDEBUG” contre “-DNDEBUG”, et “#if défini (DEBUG)”, etc.

Il est donc essentiel de tester le code que vous expédiez. Si vous générez du code différent dans les versions de débogage et de publication, cela signifie que vous devez tester deux fois, que le test soit effectué par la même personne ou non.

Les symboles de débogage ne sont pas un gros problème, cependant. Construisez toujours avec des symboles de débogage, conservez une copie du fichier binary non traité, mais publiez un fichier binary dénudé. Tant que vous étiquetez chaque binary avec un numéro de compilation d’une manière ou d’une autre, vous devriez toujours être capable d’identifier le binary non dépouillé correspondant au binary dépouillé que vous devez déboguer …

La suppression des binarys et des symboles de chargement dans votre débogueur à partir d’une source externe dépend de la plate-forme.

Notre politique est de faire en sorte que les développeurs travaillent sur des versions Debug, mais TOUT LE MONDE (QA, BA, ventes, etc.) exécute la version finale. Hier, j’ai dû corriger un bogue qui n’apparaissait que dans la version, il était évident que ce qui se passait simplement PARCE QUE cela n’apparaissait que dans la version

C’est le premier ici dans cette boutique, et je suis ici depuis environ 18 mois.

Là où les choses se compliquent, c’est quand la version Release a des effets différents sur la version de débogage – Oui, je suis allée en enfer et j’ai vu cela dans un très ancien code de production très ropy.

Je ne vois aucune raison de ne pas avoir les deux si la seule différence entre les configurations sont les symboles de débogage et les optimisations.

vous devez donc créer une version que vous pouvez éventuellement déboguer … cela peut signifier activer les symboles de débogage et désactiver certaines optimisations, même dans la version “release”.

Ummm … on dirait que tu fais un debug pour moi … non?

La partie où vous vous êtes trompé est la suivante:

Je pense qu’il est préférable de publier la version du logiciel que vos développeurs ont réellement testée

Les développeurs ne testent pas le code. Test du code de test.

Vos tests unitaires doivent tester TOUTES les configurations de construction. Ne faites pas travailler vos développeurs avec une main attachée dans le dos – laissez-les utiliser tous les outils de débogage dont ils disposent. Un build de débogage en fait partie.

En ce qui concerne les affirmations: l’utilisation des assertions dépend grandement de la programmation ou non par contrat. Si vous le faites, alors les assertions vérifient simplement le contrat dans une version de débogage.

Conformément à ma réponse dans le thread lié, nous utilisons également la même version pour le débogage et la publication pour des raisons très similaires. Les gains de performance de 10% à 20% obtenus avec l’optimiseur ont tendance à être très mineurs par rapport aux optimisations manuelles au niveau de l’algorithme. Un seul build supprime de nombreux bogues potentiels. Plus précisément;

  • Les variables non initialisées et les petits dépassements de tampon peuvent aboutir à des résultats très différents en termes de débogage et de versions optimisées.

  • Même avec les informations symboliques disponibles, le débogage d’une version optimisée peut être difficile car l’object ne correspond pas à la source, par exemple, les variables peuvent avoir été optimisées et le code peut avoir été réorganisé. Ainsi, les bogues signalés dans les versions de version testées peuvent être plus difficiles, et donc chronophages, à suivre.

Après avoir comparé des builds non optimisés et optimisés sous des tests de régression automatisés, les gains de performances fournis par l’optimisation ne fournissent pas assez de valeur supplémentaire pour avoir deux builds dans mon cas. Il peut être intéressant de noter que le logiciel que je développe est très gourmand en processeur (par exemple, créer et manipuler de grands modèles de surface).

En développant avec Java, je déteste les versions non-débogage. Lorsqu’une exception est levée, vous n’obtenez aucune information sur la ligne, ce qui rend difficile, voire impossible, le suivi des bogues. En outre, la différence d’exécution entre le débogage et le non-débogage est d’environ 5% avec Java 5 ou version ultérieure, ce n’est vraiment pas un problème et avec les disques durs actuels, la taille n’a plus d’importance.

Sur le côté positif en utilisant les versions de débogage:

  • Les traces de stack contiennent toutes les informations dont vous avez besoin
  • Les variables peuvent être examinées
  • Si vous rencontrez un problème de production, vous pouvez simplement vous connecter au processus en cours d’exécution sans avoir à arrêter le serveur pour installer une version de débogage.
  • Vous ne serez pas pris par des bogues d’optimisation intelligents
  • La construction est plus simple (un seul artefact)

Les développeurs travaillent avec des versions de débogage, QA et tout le monde utilise la version finale que nous appelons “production”. Le principal avantage de ceci est que, dans la version de débogage, nous pouvons append beaucoup de code et d’assertions supplémentaires. Certains objects contiennent des informations supplémentaires inutiles, sauf lors de l’affichage du code dans le débogueur. Certains objects se valident périodiquement pour s’assurer que toutes les informations d’état sont cohérentes. Ces choses rendent la version de débogage beaucoup plus lente, mais elles nous ont aidés à trouver des bogues qui auraient été impossibles à trouver dans la version de production.

Comme je l’ai dit, tous nos tests d’assurance qualité et de tests de performances utilisent des versions de production, et nous rencontrons parfois des problèmes qui apparaissent dans la production mais pas dans le débogage. Mais ils sont relativement rares et, en tant que développeur, les avantages du débogage d’une version de débogage plutôt que d’une version de production dépassent largement ce problème.

Je pense que cela dépend de la taille du projet et du type de système de construction et de test que vous utilisez.

Si vous avez un système de génération automatisé en place, et qu’il est simple d’exécuter des tests unitaires et fonctionnels sur une version donnée, vous ne devriez jamais avoir de problème avec plusieurs types de construction.

J’ai toujours souscrit à l’approche “Expédier ce que vous déboguez, de sorte que vous pouvez déboguer ce que vous expédiez”, pour toutes les raisons que vous avez énumérées dans votre question.

A mon avis, cette discussion manque un point très important:

Cela dépend vraiment de quel type de projet il s’agit!

Si vous créez un projet natif (C / C ++), vous serez forcé de créer des versions de débogage, simplement parce que les optimisations du compilateur peuvent rendre le débogage presque impossible dans certains cas.

Si vous créez des applications Web, vous souhaiterez peut-être simplement avoir une seule version (bien que “build” soit plutôt trompeur pour certaines applications Web), ce qui peut activer les fonctionnalités de journalisation pendant l’exécution.

Bien qu’un projet C ++ natif et une application Web PHP ne soient évidemment pas tous des projets, j’espère que mon sharepoint vue a été bien compris.

PS: lorsque vous développez pour C #, vous rencontrez une frontière car, bien que l’utilisation d’une version de débogage désactive les optimisations du compilateur, dans mon expérience, vous ne rencontrerez pas autant de différences qu’avec C ++.

Ici, nous développons en mode debug et effectuons tous les tests unitaires en mode release. Nous sums un petit magasin avec seulement quelques applications (moins de 12) à prendre en charge, allant de Classic ASP, ASP.Net, VB.Net et C #. Nous avons également une personne dédiée pour gérer tous les tests, les problèmes débogués sont renvoyés aux développeurs.

Nous construisons toujours les deux, jamais même envisagé de ne pas le faire. L’activation des options de débogage augmente la taille de votre code et ralentit les performances, peut-être pas un problème avec votre type de logiciel lors des tests, mais si le client exécute votre code plus 5 autres applications …

Les problèmes liés aux tests peuvent être résolus à l’aide de tests automatisés, ce qui permet de tester sans effort votre version lorsque vous pensez que vous êtes prêt à sortir. L’incapacité de vos développeurs ou de votre entreprise à tester correctement les versions de publication n’est pas un échec dans l’idée des versions de publication et de débogage, mais dans vos développeurs et / ou votre entreprise.

Sur votre dernier point, je n’ai jamais été appelé à déboguer une version release, juste pour la réparer …

C’est un compromis. Étant donné que les cycles de processeur sont bon marché et deviennent moins chers alors que les cycles humains restnt chers, il est très logique de ne conserver qu’une seule version d’un grand programme complexe – la version de débogage (gable).

Toujours utiliser des assertions est toujours une politique plus sûre que de ne jamais les utiliser. Si vous produisez des versions séparées de débogage et de publication, réactivez les symboles #define pour garantir que les assertions sont également activées dans la version de publication.

Je pense que le compromis est simple: oui, avec seulement une version release, vous testez vraiment ce qui est réellement expédié. D’un autre côté, vous payez un prix en facilitant le débogage pour vos développeurs et / ou en performances pour l’utilisateur, c’est donc à vous de vérifier les deux cas.

Sur la plupart des projets de taille moyenne à grande, la facilité de débogage garantira un meilleur produit pour vos utilisateurs.

En supprimant la “cible de débogage”, vous forcez les développeurs à déboguer sur la version du logiciel. Ce que cette probabilité signifie dans la pratique est deux choses:

1) les versions de compilation auront des optimisations désactivées (les autres développeurs ne peuvent pas utiliser un débogueur)

2) Aucune compilation ne disposera de macros spéciales PREPROCESSOR modifiant leur exécution.

Donc, ce que vous allez vraiment faire, c’est de fusionner les configurations de release et de debug plutôt que d’éliminer le mode “debug”.

Je l’ai personnellement fait avec le développement iOS sans aucun effet négatif. Le temps passé dans notre code écrit est inférieur à 1% de ce qui se passe réellement, de sorte que les optimisations ne sont pas des facteurs importants. Dans ce cas, ils semblaient vraiment provoquer une augmentation des bogues, mais même s’ils ne le faisaient pas, l’idée de tester un seul sens, puis de donner à un AQ avec un code différent introduit un facteur supplémentaire à prendre en compte.

D’un autre côté, il y a des cas où les optimisations sont nécessaires, où elles sont utiles, et même où il y a suffisamment de temps pour tester les deux. Habituellement, les changements entre le débogage et la publication sont si mineurs qu’ils ne causent aucun problème à quiconque.

Si vous avez un vrai groupe d’assurance qualité sur lequel vous pouvez compter pour tester complètement la chose, je dirais que faire des mises au point jusqu’à ce que vous vous rapprochiez de la version, puis vous assurer qu’un cycle complet de QA est fait sur la même construction. sortir par la porte.

Bien que dans au moins un cas, nous avons publié quelque chose qui contenait encore du code de débogage. La seule conséquence était que le tout était un peu plus lent et que les fichiers journaux étaient assez gros.

Dans mon entreprise, nous avons à la fois Debug et Release. – Les développeurs utilisent la version de débogage pour trouver et corriger correctement les bogues. – Nous utilisons TDD et nous avons une grande suite de tests que nous exécutons sur notre serveur et qui teste aussi bien les configurations de compilation de débogage et de version que les versions 64/32.

Donc, si l’utilisation de la configuration “debug” aide un développeur à trouver plus rapidement un bogue, il n’y a aucune raison de ne pas l’utiliser – lorsque le code entre dans le serveur (à tester plus avant) ou revu, nous utilisons le code “Release”.

J’ai appris à construire la version avec des fichiers .PDB il y a longtemps pour que je puisse déboguer la version. Ce que beaucoup de programmeurs ont tendance à oublier, c’est que lorsque vous exécutez la version de débogage, avec toutes les optimisations désactivées, vous déboguez complètement un programme différent. Il se comporte peut-être comme la version finale (pour la plupart), mais il s’agit toujours d’un programme différent de la version de publication.

En outre, le débogage de la version de publication n’est pas si difficile. Et si vous obtenez un vidage sur incident, vous devez pouvoir le faire quand même.

Voir ceci Quel est votre avis de programmation le plus controversé?

citation:

Opinion: Ne jamais avoir un code différent entre les versions “debug” et “release”

La principale raison étant que le code de publication n’est presque jamais testé. Mieux vaut avoir le même code en cours d’examen que dans la nature.