单独的'调试'和'发布'构建？

Question

我认为发布开发人员实际测试的软件版本会更好; 因此,我倾向于从project/makefile中删除'debug'目标,因此只有一个版本可以构建(并经过测试,调试和发布).

出于类似的原因,我不使用'断言'(参见断言总是坏的吗 ......).

一个人认为"调试"版本的原因是它更容易调试:但是,我反驳说你可能最终想要支持和调试你发布的任何东西,所以你需要建立一个版本您可以根据需要调试...这可能意味着启用调试符号,并禁用某些优化,即使在"发布"版本中也是如此.

有人说"这是个坏主意"; 这是我几年前发展起来的政策,被以下因素烧毁:

• 一些开发人员测试他们的调试但不测试发布版本
• 一些开发人员编写的bug只出现在发布版本中
• 该公司在测试不充分后发布了发布版本(它是否完全足够？)
• 被要求调试发布版本

从那时起,我看到不止一个开发商遵循这种做法(即没有单独的调试和发布版本).

你的政策是什么？

Answer 1

具有单独的调试和发布版本是一个好主意,因为它确实使开发更容易.

但是调试版本应该仅用于开发,而不是用于测试.您只测试发布版本.并且您不使用开发人员来测试这些构建,而是使用测试人员.

IMO是一个简单的政策,可以提供两全其美的优势.

编辑:在回复评论时,我认为调试和发布构建(可以)生成不同的代码显而易见.想想"-DDEBUG"与"-DNDEBUG"和"#if defined(DEBUG)"等.

因此,测试最终发布的代码至关重要.如果您确实在调试和发布版本中生成了不同的代码,则意味着测试两次 - 无论它是否由同一个人进行测试.

但是,调试符号不是一个大问题.始终使用调试符号构建,保留未提取的二进制文件的副本,但释放已剥离的二进制文件.只要您以某种方式使用内部版本号标记每个二进制文件,您应始终能够识别哪个未剥离的二进制文件对应于您必须调试的剥离二进制文件...

如何从外部源中删除调试器中的二进制文件和加载符号与平台有关.

Answer 2

这可能是次要的,但它增加了其他人在这里所说的内容.拥有QA测试版本构建的一个优点是,随着时间的推移,软件的内置调试和日志记录功能将由于开发人员的需求而有所提升,他们需要弄清楚QA中出现问题的原因.

开发人员需要调试发布版本的次数越多,客户开始遇到问题时就会有更好的工具.当然,开发人员没有理由将发布版本作为开发周期的一部分.

此外,我不知道任何软件公司有足够长的周期来支付从版本的测试期中途将QA从调试转换到发布版本的开销.必须进行完整的QA循环,这种情况经常很少发生.

Answer 3

我们的策略是让开发人员使用Debug构建,但其他人(QA,BA,销售等)运行发布版本.昨天我不得不修复一个只出现在发布版本中的bug,显而易见的是发生了什么只是因为它只出现在发行版中

这是这家店的第一家店,我已经在这里待了18个月左右.

事情变得多毛的时候,Release版本对调试版本做了不同的事情 - 是的,我去过地狱,并在一些非常古老,非常复杂的生产代码中看到了这一点.

如果配置之间的唯一区别是调试符号和优化,我认为没有理由不同时使用两者.

Answer 4

因此,您需要构建一个可以在必要时调试的版本...这可能意味着启用调试符号,并禁用某些优化,即使在"发布"版本中也是如此.

嗯......听起来你正在为我做一个调试版本......对吧？

你出错的部分就是这句话:

我认为发布开发人员实际测试的软件版本会更好

开发人员不测试代码.测试测试代码.

您的单元测试应测试所有构建配置.不要让你的开发人员单手绑在背后 - 让他们使用他们拥有的所有调试工具.Debug构建就是其中之一.

关于断言:断言的使用在很大程度上取决于你是否通过合同进行编程.如果这样做,那么断言只是在调试版本中检查合同.

Answer 5

根据我在链接线程中的答案,我们也使用相同的构建进行调试和发布,原因非常相似.与算法级别的手动优化相比,优化器10%-20%的性能提升往往非常小.单个构建消除了许多潜在的错误.特别;

• 未初始化的变量和小的缓冲区溢出可能会在调试和优化的发布版本中产生非常不同的结果.

• 即使有可用的符号信息,调试优化版本也很困难,因为对象与源不匹配,例如变量可能已被优化并且代码可能已被重新排列.因此,在测试版本构建中报告的错误可能更难以追踪并且因此耗时.

在自动化回归测试中比较未经优化和优化的构建后,优化提供的性能提升无法为我的案例中提供两个构建提供足够的额外价值.值得注意的是,我开发的软件非常耗费CPU(例如,创建和操作大型表面模型).