Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ChrisDolan (2855)

  (email not shown publicly)

Journal of ChrisDolan (2855)

Monday June 04, 2007
12:25 AM

dev vs. live

[ #33415 ]

In any web app, it seems that there's always something that you want to be different on the live site versus the dev site: a different database name, verbose logging on, performance metrics enabled, etc. I find myself implementing the live vs. dev switch a little differently every time, though. What do other people do? Do you trigger dev behavior via hostname? Via a config file? Via an URL substring? Manually?

In my current Catalyst project, I wrote this little hack. It's inelegant, but simple to understand.

# If we aren't running on my development computer, refuse to load the dev features
if (! -d '/Users/chris') {
   # trick Perl into thinking this file is already loaded
   $INC{'MyApp/Controller/'} = 1;

where adds a few special features and flags. This works because my main dev box is a Mac and the servers are all Linux or FreeBSD, which use /home instead of /Users.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'm increasing going config-driven.

    I centralize all the platform-specific stuff into a .ini or YAML-style config file.

    Then there's a config class which has the task of loading it and thoroughly checking everything in it (file permissions, paths existing, initializing the database connection pool etc). It takes a fail-early approach, and then various configuration values and objects are provided via the static methods for the config class.

    All the rest of the application looks to this class for information, s
  • If I'm deploying on mod_perl, I tend to set this sort of thing up using PerlSetVar in the Apache config rather than create an application-specific config file.

  • I've done things like that in the past (or sniffing version numbers of various programs/libraries, and guessing environment therefrom), but I suspect that way lies madness, ultimately -- at least, pick one thing and stick with it, or you will inevitably forget what the decider is for any given app.

    I tend to prefer the config file method -- it also allows a slightly wider matrix (development vs. production is common, but many leave off staging, or laptop, or home machine). Ideally, there would be two axes:

  • I use a second config file where I put site specific values. The application loads both config files, values in the second one override those in the first config file. This way no ugly code hacks like the one you posted.
  • If you have a "dev -> stage -> prod" setup, where stage is ideally as close as possible to prod, then what you have won't work. You need a more general way to get the configuration, like a config layer that parts of the application can call through (database, etc. goes through this layer).

    Dealing with different configurations sucks, blech. Like when you want to sync your dev from prod, you always end up changing something: a server name in a database table, in a config file, etc. I guess ideally you