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

Question

Je pense que c'est mieux de libérer la version du logiciel que vos développeurs de test; j'ai donc tendance à supprimer le "debug" cible du projet/makefile, de sorte qu'il n'y a qu'une seule version qui peut être construit (et testé, et débogué, et publié).

Pour une raison similaire, je n'utilise pas "assertions" (voir également http://stackoverflow.com/questions/419406/are-assertions-always-bad#419410 ...).

Une personne n'a fait valoir que la raison pour laquelle une version de déboguage, c'est que c'est plus facile à déboguer: mais, je me contre-dire que vous peut éventuellement veulent soutenir et de débogage, quel qu'il soit, vous avez publié, et si vous avez besoin de construire une release qui vous pouvez si nécessaire debug ... cela peut permettre symboles de débogage, et la désactivation de certaines optimisations, même dans la "libération" de construire.

Quelqu'un a dit que "c'est une mauvaise idée"; c'est une politique qui j'ai évolué il y a quelques années, après avoir été brûlé par:

• Certains développeurs de tester leurs debug, mais pas les versions
• Certains développeurs d'écriture des bugs qui apparaissent uniquement dans la version
• La société en relâchant la version d'après l'analyse inadéquat (est-il jamais tout à fait suffisante?)
• D'être appelé à la version de débogage

Depuis j'en ai vu plus d'une autre au développement de la boutique de suivre cette pratique (c'est à dire ne pas avoir séparé debug et release).

Quelle est votre politique?

Answer 1

Cela peut être mineur, mais il ajoute à ce que les autres ont dit ici. L'un des avantages d'avoir la QA de test release est qu'au fil du temps construit dans le débogage et la journalisation des capacités de votre logiciel avance en raison des besoins des développeurs qui ont besoin de comprendre pourquoi les choses vont mal dans l'assurance qualité.

Le plus, les développeurs ont besoin de déboguer les versions release, les meilleurs outils que vous aurez plus tard, lorsque les clients commencent à avoir des problèmes. Bien sûr, aucune raison pour les développeurs de travailler sur les versions release dans le cadre du cycle de développement.

Aussi, je ne connais pas de logiciel qui a assez longtemps cycles de payer les frais généraux de commutation de l'AQ de débogage pour publication s'appuie à mi-chemin à travers une version de la période d'essai. Avoir à faire un cycle d'assurance qualité est quelque chose qui, trop souvent, se produit assez rarement.

Answer 2

Notre politique est d'avoir des développeurs de travailler sur les versions de Débogage, mais TOUS les autres, (AQ, les BAs, les ventes, etc) exécute la version. Hier, j'ai eu à corriger un bug qui n'est apparu que dans la version release, il était évident que ce qui se passait tout simplement PARCE qu'il n'est apparu que dans la version

C'est d'abord un ici, dans cette boutique, et j'ai été ici 18 mois.

Là où les choses deviennent poilu, c'est quand la version Release n'différentes choses pour la version debug - Oui, j'ai été en Enfer et vu ce très vieux, très filantes code de production.

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 d'optimisation.

Answer 3

donc, vous avez besoin pour créer une version qui vous pouvez, si nécessaire, debug ... ce peut permettre symboles de débogage, et la désactivation de certaines optimisations, même dans la "libération" de construire.

Ummm... on dirait que vous êtes en train de faire une version de débogage pour moi... droit?

La partie où vous êtes allé mal, c'est cette déclaration:

Je pense que c'est mieux de libérer la version du logiciel de votre les développeurs de test

Les développeurs n'avez pas de code de test. Tests de code de test.

Vos tests unitaires doit tester TOUTES les configurations de build. Ne faites pas vos développeurs de travailler avec une main liée derrière le dos - laissez-les utiliser tous les outils de débogage ils ont à leur disposition. Une version de Débogage est l'un de ces.

Concernant l'affirme: l'utilisation des assertions dépend en grande partie sur si oui ou non vous programme par contrat. Si vous le faites, alors les assertions de simplement vérifier le contrat dans une version de débogage.

Answer 4

Comme par ma réponse dans le fil relié, nous pouvons aussi utiliser la même version de debug et release pour des raisons très semblables. Les 10%-20% de gains de performances de l'optimiseur ont tendance à être très mineur par rapport à manuel des optimisations au niveau de l'algorithme de. Une construction unique supprime de nombreux bugs potentiels. En particulier;

• Non initialisée variables et les petits dépassements de la mémoire tampon peut se retrouver avec des résultats très différents dans le débogage et l'optimisation release.

• Même avec la symbolique de l'information disponible, le débogage d'une version optimisée peut être difficile, car l'objet ne correspond pas à la source, par exemple, les variables peuvent avoir été optimisé et le code peut avoir été ré-arrangé. Ainsi, les bogues rapportés dans testé les versions release peut être plus difficile, et donc du temps, de la piste vers le bas.

Ayant comparé unoptimised et optimisé construit sous automatisé de tests de régression, les gains de performance fournies par l'optimisation ne fournissent pas suffisamment de valeur supplémentaire d'avoir deux versions dans mon cas. Il est peut être intéressant de noter que le logiciel que je développe est très CPU de la faim (par exemple, la création et la manipulation de grands modèles de surface).