Separate 'debug' and 'release' bui

Question

I think it's better to release the version of the software which your developers actually tested; I therefore tend to delete the 'debug' target from the project/makefile, so that there's only one version that can be built (and tested, and debugged, and released).

For a similar reason, I don't use 'assertions' (see also Are assertions always bad? ...).

One person there argued that the reason for a 'debug' version is that it's easier to debug: but, I counter-argued that you may eventually want to support and debug whatever it is you released, and so you need to build a release which you can if necessary debug ... this may mean enabling debug symbols, and disabling some optimizations, even in the 'release' build.

Someone else said that "this is such a bad idea"; it's a policy I evolved some years ago, having been burned by:

• Some developers' testing their debug but not release versions
• Some developers' writing bugs which show up only in the release version
• The company's releasing the release version after inadequate testing (is it ever entirely adequate?)
• Being called on to debug the release version

Since then I've seen more than one other development shop follow this practice (i.e. not have separate debug and release builds).

What's your policy?

Answer 1

In my company we have both Debug and Release. - The developers use the debug version to properly find and fix bugs. - We are using TDD and so we have a big test suite that we run on our server that tests both debug and release build configurations as well as 64/32 builds we have as well.

So if using the "debug" configuration helps a developer to find a bug faster there is no reason not to use it - when the code goes into the server (to be further tested) or reviewed we use the "Release" one.

Answer 2

See this What's your most controversial programming opinion?

quote:

Opinion: Never ever have different code between "debug" and "release" builds

The main reason being that release code almost never gets tested. Better to have the same code running in test as it is in the wild.

Answer 3

By removing the "debug target", you are forcing developers to debug on the release version of the software. What that probaly means in practice is two things:

1) "release builds" will have optimizations disabled (otherwised developers can't use a debugger)

2) No builds will have special PREPROCESSOR macros altering their execution.

So what you will really be doing is merging the release and debug configurations rather than eliminating just the "debug" mode.

I personally have done this with iOS development with no ill-effects. The amount of time spent in our written code is less than 1% of what is really happening, so the optimizations were not significant contributors. In this case, they really did seem to cause an increase in bugs, but even if they didn't, the idea of testing one way, then giving to QA with different code introduces just one more factor to consider with issues.

On the other hand, there are cases where the optimizations are necessary, where they are useful, and even where there is enough time for testing both. Usually, the changes between debug and release are so minor that it doesn't cause anyone any issues at all.

Answer 4

I think it depends on the project size and what type of build system and testing that you are using.

If you have an automated build system in place, and it's simple to run unit and functional tests on a given build, then you should never have any problems with multiple build types.

Answer 5

When developing with Java, I hate non-debug versions. When an exception is thrown, you get no line information which makes it hard or even impossible to track bugs down. Also, the runtime difference between debug and non-debug is around 5% with Java 5 or later, so this is really no issue and with todays hard disks, size doesn't matter anymore.

On the plus side using debug versions:

• Stack traces contain all the information you need
• Variables can be examined
• If you have a problem in production, you can simply attach to the running process without having to stop the server first to install a debug version.
• You won't get caught by clever optimization bugs
• The build is more simple (just one artifact)

Answer 6

Developers work with debug builds, QA and everyone else uses the release version, which we call "production". The main advantage to this is that in the debug build, we can add lots of extra code and assertions. Some objects contain extra pieces of information that have no use except when viewing code in the debugger. Some objects validate themselves periodically to make sure that all the state information is consistent. These things make the debug version much slower, but they have helped us find no end of bugs that would have been hell to find in the production build.

As I said, all of our QA and performance testing uses production builds, and we do occasionally run into problems that show up in production but not in debug. But they're relatively rare, and as a developer, the advantages of debugging a debug build rather than a production build far outweigh that problem.