Re: Re: Supporting a production environment

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!

Comment on Re: Re: Supporting a production environment

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re: Supporting a production environment
by Abigail-II (Bishop) on May 07, 2004 at 23:07 UTC

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]