Environment Variables - Dev/Test/Production?

Woody asks: "It's common knowledge that the development environment should be the same as the test environment which should mimic the production environment whenever possible. I'm currently working on a project where we develop on Dell, test on IBM, and the production system is up in the air. For embedded systems the differences can be running on a VM versus running on the actual hardware. What I want to know is what kind of problems have Slashdot readers been faced with because of different environments being used for different phase of their projects, and how have they been overcome?"

Re:To the other extreme with NDEBUG/assert()

[stoborrobots]

And a different question: Why would you compile with different options in the test and production builds? That would kind of invalidate the testing.

You shouldn't compile with different options between test and production, but you should do so (for things like -DDEBUG) between dev and test... developers need their extra debugging statements, and asserts, but they interfere with appropriate user interfacing in production.

As I see it, the steps are:
1. Develop
2. Test in production mimiced environment with -DDEBUG (still part of development phase)
3. Hand off to QA phase to test in production mimiced environment without -DDEBUG ("production version")
4. Release "production version" to production.

(obligatory...
5. ???
6. CODE NIRVANA! )

Continous integration

[maxmg]

We are developing J2EE applications using a continous integration server (currently anthill open source [urbancode.com], but others are available). Ant is used for building, testing and deploying.
Now we have a number of environment-specific settings, for example database connection details, etc.
All environment-specific stuff goes into .properties files which are included conditionally by the ant script (based on a single environment variable or ant parameter). All of those properties files live in a directory conf/<environment name>, where environment name is either a developer's name, or "test", "production", "staging", etc. Each night, new deployment packages for each of the different deployment targets (test, prod, etc.) are built and made available through anthill. Some of those targets are also automatically deployed for the testing team every night, so the latest features are always available to be tested somewhere the next day.
Every successful build is tagged in CVS with an autoincrementing build number. When we have identified a release candidate, it is as simple as instructing anthill to (re)build a deployment bundle for a particular target with a specific build number. That deployment bundle (usually a .ear or .war) is then simply dropped into the production environment - remember that all the environment-specific settings are already included in that particular bundle. The benefit of this is that all environmental settings are maintained in the main source repository, the downside being that different packages exist for the different targets, but in practice that has not proved to cause any problems.
An additional benefit is that each environment's individual settings (including development machines) is always available to all developers for comparison and troubleshooting.
I guess the lesson learned is this:

• Automate your build!
• Extend your build system to include the environmental configuration
• Automatically build separate targets for different environments