Séparez les versions 'debug' et 'release'?

Question

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’une seule version puisse être construite (et testée, puis déboguée et publiée).

Pour une raison similaire, je n'utilise pas d'assertions (voir aussi les assertions sont-elles toujours mauvais? ...).

Une personne a fait valoir que la raison d’une version de "débogage" est qu’il est plus facile de déboguer: mais, je l’ai contre-argument une version que vous pouvez si nécessaire déboguer ... cela peut signifier l’activation des symboles de débogage et la désactivation de certaines optimisations, même dans la version 'release'.

Quelqu'un a dit "c'est une si mauvaise idée"; c'est une politique que j'ai élaborée il y a quelques années, après avoir été incendiée par:

• Certains développeurs testent leurs versions de débogage mais pas les versions
• Quelques bogues d'écriture de développeurs qui n'apparaissent que dans la version
• La société a publié la version publiée après des tests insuffisants (est-il de jamais tout à fait adéquat?)
• Être appelé à déboguer la version publiée

Depuis lors, j'ai vu plus d'un atelier de développement suivre cette pratique (c'est-à-dire ne pas avoir de versions de débogage et de version séparées).

Quelle est votre politique?

Answer 1

Cela peut être mineur, mais cela s’ajoute à ce que d’autres ont dit ici. L’un des avantages des versions de test de contrôle qualité est qu’au fil du temps, les fonctionnalités intégrées de débogage et de journalisation de votre logiciel évolueront en raison des besoins des développeurs qui doivent comprendre pourquoi les problèmes de contrôle qualité se produisent.

Plus les développeurs ont besoin de déboguer les versions des versions, meilleurs sont les outils que vous pourrez utiliser plus tard lorsque les clients commencent à avoir des problèmes. Bien entendu, les développeurs n’ont aucune raison de travailler sur les versions des versions dans le cadre du cycle de développement.

De plus, je ne connais aucun éditeur de logiciels qui dispose de suffisamment de cycles pour supporter le surcoût du passage de l'assurance qualité du débogage à la version finale à mi-parcours de la période de test d'une version. Devoir faire un cycle complet d'assurance qualité est quelque chose qui arrive trop souvent très rarement.

Answer 2

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

Mais les versions de débogage doivent être uniquement destinées au développement, pas aux tests. Vous testez uniquement les versions validées. Et vous n’utilisez pas les développeurs pour tester ces versions, vous utilisez des testeurs.

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

Modifier: En réponse à un commentaire, il est évident que les versions de débogage et de publication génèrent (peuvent) générer un code différent. Pensez " -DDEBUG " vs "-DNDEBUG", et "#if defini (DEBUG)", etc.

Il est donc essentiel que vous testiez le code que vous avez envoyé. Si vous générez un code différent dans les versions de débogage et de version, cela signifie que vous devez tester deux fois, qu'il soit testé ou non par la même personne.

Les symboles de débogage ne sont toutefois pas un gros problème. Construisez toujours avec des symboles de débogage, conservez une copie du fichier binaire non décomposé, mais publiez un fichier binaire épuré. Tant que vous balisez chaque numéro binaire avec un numéro de construction, vous devriez toujours pouvoir identifier le fichier binaire non fragmenté qui correspond au fichier binaire extrait que vous devez déboguer ...

La suppression des fichiers binaires et le chargement des symboles dans votre débogueur à partir d'une source externe dépendent de la plate-forme.

Answer 3

Notre politique est de faire en sorte que les développeurs travaillent sur les versions Debug, mais TOUT LE MONDE (QA, BA, ventes, etc.) exécute la version finale. Hier, je devais corriger un bogue apparaissant uniquement dans la version, il était évident que ce qui se passait était simplement PARCE QUE cela ne se soit produit que dans la version

.

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

Les choses deviennent plus difficiles, c'est lorsque la version Release fait quelque chose de différent de la version de débogage - Oui, je suis allé en enfer et je l'ai vu dans un code de production très ancien et très ropy.

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

Answer 4

  

vous avez donc besoin de créer une version qui   vous pouvez si nécessaire déboguer ... ceci   peut signifier l'activation des symboles de débogage, et   désactiver certaines optimisations, même dans   la version 'release'.

Ummm ... on dirait que vous faites un build de débogage pour moi ... non?

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

  

Je pense qu'il vaut mieux libérer le   version du logiciel que votre   les développeurs ont effectivement testé

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

Vos tests unitaires doivent tester les configurations de génération ALL . Ne faites pas travailler vos développeurs avec une main attachée derrière le dos - laissez-les utiliser tous les outils de débogage dont ils disposent. Une construction Debug en fait partie.

En ce qui concerne les assertions: l’utilisation d’assertions dépend grandement de la programmation par contrat ou non. Si vous le faites, les assertions ne font que vérifier le contrat dans une version de débogage.

Answer 5

Conformément à ma réponse dans le fil de discussion 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 l'optimiseur de 10% à 20% tendent à être très mineurs par rapport aux optimisations manuelles au niveau de l'algorithme. Une seule version supprime de nombreux bugs potentiels. Plus précisément;

• Les variables non initialisées et les petits débordements de mémoire tampon peuvent aboutir à des résultats très différents dans les versions de débogage et de version optimisées.

• Même avec les informations symboliques disponibles, le débogage d'une version optimisée peut s'avérer difficile car l'objet ne correspond pas à la source, par exemple. les variables peuvent avoir été optimisées et le code peut avoir été réarrangé. Par conséquent, les bogues signalés dans les versions de versions testées peuvent être plus difficiles, et donc fastidieux, à localiser.

Après avoir comparé les versions non optimisées et optimisées dans le cadre de tests de régression automatisés, les gains de performances fournis par l’optimisation ne fournissent pas suffisamment de valeur supplémentaire pour que deux versions soient possibles dans mon cas. Il convient de noter que le logiciel que je développe est très gourmand en ressources processeur (par exemple, la création et la manipulation de modèles de grandes surfaces).

Answer 6

Lors du développement avec Java, je déteste les versions non déboguées. Lorsqu'une exception est générée, vous ne recevez aucune information de ligne qui rend difficile, voire impossible, le traçage 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 une version ultérieure, ce n’est donc pas un problème et avec les disques durs d’aujourd’hui, la taille n’importe plus.

Coté positif avec les versions de débogage:

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

Answer 7

Les développeurs travaillent avec des versions de débogage, une assurance qualité et tout le monde utilise la version de publication, que nous appelons "production". Le principal avantage est que dans la version de débogage, nous pouvons ajouter beaucoup de code et d’assertions supplémentaires. Certains objets contiennent des informations supplémentaires inutiles, sauf lors de l'affichage du code dans le débogueur. Certains objets se valident régulièrement 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 sans fin des bugs qui auraient été un enfer à trouver dans la version de production.

Comme je l’ai dit, tous nos tests d’assurance qualité et de performances utilisent des versions de production, et nous rencontrons parfois des problèmes qui apparaissent en production mais pas en 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 de loin ce problème.

Answer 8

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

Si vous disposez d'un système de génération automatisé et qu'il est simple d'exécuter des tests unitaires et fonctionnels sur une génération donnée, vous ne devriez jamais rencontrer de problèmes avec plusieurs types de construction.

Answer 9

Je me suis toujours abonné à la rubrique "Expédier ce que vous déboguez, afin que vous puissiez déboguer ce que vous envoyez". approche, pour toutes les raisons que vous avez énumérées dans votre question.

Answer 10

À mon avis, cette discussion manque d'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, tout 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 voudrez peut-être simplement avoir une version (bien que "construction" soit plutôt trompeuse pour certaines applications Web) qui puisse 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 les types de projets existants, j'espère que mon argument est bien compris.

P.S .: Lors du développement pour C #, vous rencontrez un cas limite, car bien que l'utilisation d'une version de débogage désactive les optimisations du compilateur, vous ne rencontrerez peut-être pas autant de différences qu'en C ++

Answer 11

Ici, nous développons en mode débogage et faisons tous les tests unitaires en mode release. nous sommes un petit magasin avec seulement quelques applications (moins de 12 ans) à 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 de débogage sont renvoyés aux développeurs.

Answer 12

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, ce qui ne pose probablement pas de problème lors du test de votre type de logiciel, mais que se passe-t-il 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. Ainsi, votre version de publication peut être testée sans effort lorsque vous pensez être prêt à être publié. Si vos développeurs ou votre entreprise ne testent pas correctement les versions des versions, ce n’est pas un échec de l’idée des versions de version et de débogage, mais bien de vos développeurs et / ou de votre société.

Sur votre dernier point, je n’ai jamais été invité à déboguer une version corrigée, juste pour la corriger ...

Answer 13

C'est un compromis. Étant donné que les cycles de processeur sont peu coûteux et de moins en moins chers, alors il est logique de ne conserver qu'une seule version d'un programme complexe et volumineux, 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 distinctes de débogage et de publication, réactivez tous les symboles #define dont vous avez besoin pour garantir que les assertions sont également activées dans la version de l'édition.

Answer 14

Je pense que le compromis est simple: oui, avec seulement une version validée, vous testez réellement ce qui est réellement livré. D'autre part, vous payez un prix pour faciliter le débogage pour vos développeurs et / ou les performances pour l'utilisateur, il vous appartient donc de vérifier les deux cas.

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

Answer 15

Voir ce Quel est votre avis sur la programmation le plus controversé?

citation:

  

Opinion: ne jamais avoir différent   code entre " débogage " et " relâcher "   construit

     

La principale raison étant cette version   le code n'est presque jamais testé. Mieux   avoir le même code en cours de test   à l'état sauvage.

Answer 16

En supprimant la "cible de débogage", vous obligez les développeurs à déboguer la version finale du logiciel. Ce que cela signifie probablement en pratique est double:

1) " release builds " les optimisations seront désactivées (les développeurs autrement ne peuvent pas utiliser de débogueur)

2) Aucune construction ne comportera de macros PREPROCESSOR spéciales modifiant leur exécution.

Ce que vous allez vraiment faire est donc de fusionner les configurations de publication et de débogage plutôt que d'éliminer uniquement le "débogage". mode.

Personnellement, je l’ai fait avec le développement iOS sans effets pervers. Le temps passé dans notre code écrit représente moins de 1% de ce qui se passe réellement, donc les optimisations ne sont pas des contributeurs significatifs. Dans ce cas, ils semblaient vraiment causer une augmentation du nombre de bogues, mais même s’ils ne l’avaient pas fait, l’idée de tester une méthode, puis de donner à l’assurance qualité un code différent ne présente qu’un facteur supplémentaire à prendre en compte dans les problèmes.

D’autre part, il existe des cas où les optimisations sont nécessaires, utiles, et même lorsque le temps est suffisant pour tester les deux. Habituellement, les changements entre le débogage et la publication sont tellement mineurs que cela ne pose aucun problème à personne.

Answer 17

Si vous avez un vrai groupe d’assurance qualité sur lequel vous pouvez compter pour tester pleinement le projet, je vous conseillerais de créer des versions de débogage jusqu’à ce que vous approchez de la publication, puis de vous assurer qu’un cycle d’assurance qualité complet est effectué. même construction qui sort de la porte.

Bien que dans au moins un cas, nous ayons publié quelque chose qui contenait encore du code de débogage. La seule conséquence a été que cela a fonctionné un peu plus lentement et que les fichiers journaux étaient très volumineux.

Answer 18

Dans mon entreprise, nous avons à la fois Debug et Release. - Les développeurs utilisent la version de débogage pour rechercher et corriger correctement les bogues. - Nous utilisons TDD et nous avons donc une grande suite de tests que nous exécutons sur notre serveur, qui teste à la fois les configurations de build de débogage et de publication, ainsi que les builds 64/32 que nous avons également.

Donc si vous utilisez le "débogage" La configuration aide un développeur à trouver un bogue plus rapidement, il n’ya aucune raison de ne pas l’utiliser. Lorsque le code est envoyé sur le serveur (pour être testé plus avant) ou révisé, nous utilisons le "Communiqué". un.

Answer 19

J'ai appris à construire la version de publication avec les fichiers .PDB il y a longtemps pour pouvoir 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 un programme différent. Il peut se comporter comme la version de la version (pour la plupart), mais il s’agit toujours d’un programme différent de celui de la version.

De plus, le débogage de la version release n'est pas si difficile. Et si vous recevez un crash, vous devez pouvoir le faire quand même.