http://www.perlmonks.org?node_id=560489


in reply to Migrating Code From Test to Production: How to do it right, how to set up an environment that leaves nothing to chance

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
    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 really like this design, and I employ it myself. I find it very, very handy to be able to "go live" after I have tested the system in production (but not generally seen by everyone).

    An "on" switch has other benefits: I value the ability to "launch" at a particular time that meets the customers expectation. This would be otherwise difficult to do because installations take time. "On" switches are virtually instantaneous

    Conversely, this implies an "off" switch which can be useful in some circumstances.

    -------------------------------------
    Nothing is too wonderful to be true
    -- Michael Faraday