I have worked for several companies which have tried to establish a 'representative' development environment, only to find that there were significant differences between the development and production environments which made code migration problematic.
When it comes down to it, I would argue that there is no substitute for actually trying your software in production. For that reason, I try to write my code in a partitioned manner so that I can migrate nearly all of my code to a production environment without actually going 'live'. This may require a database switch that causes the 'write' portions of your code to point to a test database, or even (as may be the case with some major online retailers) require you to partition off a redundant portion of your production environment for a 'one box test'.
I used to go to great lengths to package up my software in a Solaris environment so that my code could be 'cleanly' installed by operations folks while I stood nervously in the background. I spent a lot of time writing the installation scripts, and I never did quite account for every possible environmental difference. Whenever I can, I leave nothing to chance by being the guy who migrates the software and having a full set of test scripts that exercise the code once it is installed in production.
No good deed goes unpunished. -- (attributed to) Oscar Wilde
|Replies are listed 'Best First'.|
Re^2: Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance
by freddo411 (Chaplain) on Jul 12, 2006 at 22:01 UTC