Best practices for distinguishing "development" from "production?"

locked_user sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:

Here is a common question relating to web-development that came up in conversation yesterday. I gave my answer, but I wonder ... what is the best answer? Only one way to find out ... “Humbly Petition The Monks.™” :-)

The question was: what is the best way to construct code such that it is easily deployed among various (Apache) web-server environments, such that:

The code, when running, can readily distinguish between them (e.g. for development vs. production) environments, say to run different libraries between each.
A single body of code can be deployed, without change, and it will run appropriately in each case. (Yes, this is omitting very-interesting possibilities that are achievable using more-advanced techniques like MakeMaker, which could actually install different things in different settings ... although if anyone wants to go in that direction with this thread I don’t mind.)
The code that does it is simple, reliable, self-evident, and doesn&rsquot; impose complicated <VirtualHost> file tweaks.

The approach that I suggested was to use the SetEnv directive to set an environment variable and then use this to choose among use lib statements (each one of which uses FindBin to discern where we are). I favor this approach over using SetEnv PERL5LIB and what-not.

Over a friendly virtual brevé, my friend retorted, “no, what you should be doing is using symbolic links, because then if something screws-up badly you can just replace the link on-the-spot.”

The conversation petered on for a little while, then pleasantly changed subject. But I wonder... what say The Monks? What approach did you finally settle upon, and why?

Replies are listed 'Best First'.
Re: Best practices for distinguishing "development" from "production?" by roboticus (Chancellor) on Apr 19, 2011 at 03:00 UTC
sundialsvc4: I think it's usually a mistake when you write code that tries to tell the difference between production and development modes. I normally try to put that information in the configuration. After all, when you test your code, don't you want to test the stuff that's going to run in production? I wouldn't want to test my non-production branches and have untested production code. But, as JavaFan mentioned, it would be hard to pin down a particular best. Your "best" way may differ from my "best" way, primarily because I'll have a different notion of best than you will. ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]
Re: Best practices for distinguishing "development" from "production?" by moritz (Cardinal) on Apr 19, 2011 at 13:15 UTC
The code, when running, can readily distinguish between them (e.g. for development vs. production) environments, say to run different libraries between each. I use environment variables for that. You don't want the code to do autodetection based on the environment, because you benefit from having development/staging/production servers to be very similar. A single body of code can be deployed, without change, and it will run appropriately in each case. There are pre-made solutions for that, see Plack. The code that does it is simple, reliable, self-evident When dealing with different webserver environments? Surely you must be joking. The best you can do is reuse well-test solutions. They can be reliable, and maybe their usage is simple, and evident from the documentation. Perl 6 - second systems done right	[reply]
Re: Best practices for distinguishing "development" from "production?" by JavaFan (Canon) on Apr 18, 2011 at 22:25 UTC
what is the best way to construct code such that it is easily deployed among various (Apache) web-server environments, Only an absolute beginner would have the notion there's a best way. Anyone with a bit of experience will know that all ways suck, and it whether way X will suck less than way Y will differ from environment to environment.	[reply]
Re: Best practices for distinguishing "development" from "production?" by fidesachates (Monk) on Apr 19, 2011 at 14:25 UTC
As stated already, I find writing code that will work in all environments and letting configuration files distinguish the difference to work well. Personally I write my scripts to read from a xml configuration file and have my programs read that xml config to lead in values particular to that environment. In my line of work where we have over 200 different production environments and the same amount in dev and uat, this xml config allows me to not only distinguish between prod and dev, but also between different prod environments I need to deploy to as well. Thing most important lesson I've learned is to write code to ensure that the config values are valid.	[reply]
Re: Best practices for distinguishing "development" from "production?" by InfiniteSilence (Curate) on Apr 19, 2011 at 13:02 UTC
My 2 bits: "can readily distinguish between them..." - I would build a very simple independent mod_perl based utility that returns a simple 'PRODUCTION'\|'PILOT'\|'DEVELOPMENT' and servername combination upon invocation in XML\|Plain Text\|JSON formats (depending upon input variables) and deploy on all of my servers. If you really want to get smart you can add more stuff like for production -- you could give a list of associated pilot and development systems but then you could be creating a maintenance nightmare for yourself if not careful. A single body of code can be deployed, without change, and it will run appropriately in each case.. - Sorry, can't help you with the 'run appropriately'...stuff is always going to break. It is the law of the jungle. You can, depending on the standard, predictable results from your web service, fork the code to do different things. I fully understand how this can be necessary. For instance, if you have an application that notifies administrators when something happens you DON'T want it to send 1K e-mails from some darn pilot instance. ... complicated <VirtualHost> file tweaks... - Yeah, as I said, make your own webservice and make it read from something uber-reliable like DBM or something. Celebrate Intellectual Diversity	[reply]
Re: Best practices for distinguishing "development" from "production?" by anonymized user 468275 (Curate) on Apr 19, 2011 at 14:04 UTC
Generally I avoid using symbolic links for Apache because I may need operations applications for webadmins that can easily navigate the directories. SetEnv also doesn't really deliver the requirement exactly as you specify it. I am not sure what kind of problem you are having with virtual hosts, but I have always thought that they are by far the simplest basis for managing multiple apache environments from the same installation. One world, one people	[reply]