17

One of the practices set out in Jez Humble's Continuous Delivery is that you should build one package and then release it to each environment you deploy to, so that the deployment and the artifacts have themselves been tested multiple times before going to production.

I fully support this idea.

On the other hand, debug-mode builds that give you stack traces with line numbers are incredibly useful in test environments, as is the ability to remote-debug. But, you want to send a release build to production.

So, for people following the first principle, at what point do you switch from debug to release builds?

Is it before the first deployment to a test environment, figuring the cost of losing debug mode is worth paying to ensure you are testing the actual release candidate early? Or do you build again at some point in the promotion process, figuring that you'll trust the build process over the software? Or do you just screw it all and deploy debug versions to production?

Note: I know this doesn't really apply to interpreted languages because you can usually flick the switch in configuration rather than doing it at build time.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • Thanks all for your answers. Good food for thought. But I think "The point of changing builds depends mostly on the reproduction costs for errors" gets the tick for clearing my thought process. – pdr Nov 17 '11 at 15:52

4 Answers4

5

So, for people following the first principle, at what point do you switch from debug to release builds?

We switch early, when the source code got a version number and got pushed into the Debian build queue. We are in the lucky situation of doing scientific software with well-specified inputs and outputs and little system interaction, though, so the cost of reproducing an error situation is fairly low.

This is also my general answer: The point of changing builds depends mostly on the reproduction costs for errors. If these are very high, I'd even ship debug builds to test customers. While that carries the risk of build failures for the production build, this could still be cheaper than spending weeks in test case reproduction.

thiton
  • 5,348
  • 1
  • 27
  • 26
3

So, for people following the first principle, at what point do you switch from debug to release builds?

As soon as we go to QA we switch to release builds. But when ever we build a release build our build process also builds a debug version of the dlls. This allows us to quickly drop the debug dlls into the QA environment and get additional information if required.

Both the release and debug versions of the dlls are backed up and kept for several years.

armitage
  • 652
  • 4
  • 11
2

In our environment, the code gets deployed at many sites. And hence there should be different context applied to each instance of deployment. Usually, we deploy it in a key "lesser risky" places and see the experience.

This deployment still are in production hence, this is not 'debug' mode. But it also assumes that testing is done well.

Of course, with debug mode off, quick debug of the code (on site) might be difficult. But if the release has failed, the production switches back to fall back release.

However, we try to maintain or create an identical environment, which can reproduce such an environment to test again. (I know this is not alway trivial to do) but all we need sometimes is to reproduce the transactions/inputs.

The point is, how much ever the temptation, debug mode release should not be in production. Though, i won't say this is a rule.

Another thing is, the release is still called trial till it has established (by running for significant time) other premises don't accept it yet.

There are other few practices to ensure that build process itself not quite faulty. See this: A simple ways to improve the release quality in RAD environment

Community
  • 1
Dipan Mehta
  • 10,542
  • 2
  • 33
  • 67
2

We have our developer machines set up to build debug builds. But once the devs commit code, a deployment package is created in our continuous integration environment (TeamCity) and that is built for release. So whenever we decide to deploy to QA, we take the latest deployment package from the CI server and push it out, so it is always release unless it is on a dev machine.

BTW, for some languages, even when building for release, you can still create debug symbols. In .NET, for example, there is a "pdb-only" setting which allows for optimizations but still creates debug files. Obviously debugging against a release version is trickier since it isn't line-for-line equivalent, but it can still be helpful in a pinch.

RationalGeek
  • 10,077
  • 7
  • 38
  • 56