Re: Supporting a production environment

As Abigail-II says, the right way to do this is to have independent environments for development, QA and production. Sometimes the realities of life place developers in a position where they can't get that, no matter how clearly they know why they need to, and the desire for a paycheck keeps you there.

If that is your situation, then one solution is that you can create some form of Local::Config module whose purpose is to look at some combination of user, environment variables, configuration files, command line arguments or whatever else you choose to decide what version of the code to run. Then it should adjust @INC to fit that, and can also set key variables. For instance you likely will want development code to connect to a different database instance than production code - that can be set up here. This module should be kept as small and simple as possible because updating it is a real PITA. (I'd suggest having the configuration module figure out what version you are running, and then load the real configuration module of that version. That module now can set all environment variables that you need, special configuration information etc. This makes developing and rolling out a new configuration variable much easier - the global module never gets touched. Only the one that it loads.)

If your needs are simple, you can just specify some environment variables that make the switch, and create some shell aliases to make it easy for you to switch between them. However once you have 3-4 variables to keep on flipping together, having the configuration module is a lifesaver.

Comment on Re: Supporting a production environment

Replies are listed 'Best First'.
Re: Re: Supporting a production environment by jeb6kids (Initiate) on May 04, 2004 at 15:38 UTC
Thanks! You're Good! How to implement independent environments for development, QA and production using Perl is exactly what I was asking... (although I horribly failed to make this clear to Abigail-II (forgive me)). I think your solution has great merit and will begin now to understand better this idea of dynamic changes to @INC... for some reason I was believing that @INC must be fairly static except for some simple compile-time tweaks as I was already using. I always thought that Packages were loaded by searching the @INC path and that little or no "execution" took place until all the "use Package;" statments had been seen. You are very enlightened. Thanks again!	[reply]
Re: Supporting a production environment by Abigail-II (Bishop) on May 07, 2004 at 23:07 UTC
It's hard to give any specifics, as they require much more knowledge of your product(s) and environments, so I keep it very general. But what I am going to say is not Perl specific, and if you are looking for specific Perl answers, you are approaching this the wrong way. Separating production and testing, and upgrading production are general engineering problems - and have nothing to do with the language(s) being used. What you need is hardware, and most of all, procedures. To keep your production running smoothly, you need procedures, and you need everyone to follow the procedures. Sanctions for breaking the procedures should be severe - like firing the offender. You need at least three different environments: development, testing and production, and perhaps more (staging, several levels of testing, release). Out of development should come easy (as in, automatically) to install packages (SUN packages, HP depot files, RPMs, your own deployment tool). Your testing environment should be as much a copy of your production environment as possible (identical hardware, same OS, same version of libraries/tools, recent copy of data, etc). Install the package that comes out of development in your testing environment - if the install fails, throw it back to development, and restore your testing environment. If the installation succeeds, run your tests. Test all new functionality. Run your regression tests making sure nothing that shouldn't have changed did. Run more tests. Let everyone bring in their kids and let them bang on the keyboards for a day. Run your tests and regressions tests again. If satisfied, scedule a maintainance window for your production environment. In the maintainance window, do a full backup of your production environment. Check whether you can actually restore from the backup you made. Upgrade your production environment. Close your maintainance window and go home. Be back in before the first user starts work. Abigail	[reply]