in reply to Perl Management

In our shop (which creates and maintains a medium sized web site), we put perl in a central location (/usr/local/bin/perl). All the CPAN modules we use also stay in the default locations. All the modules we build go in a special directory that we add to @INC when we build perl. The modules we build are CVS'ed - the stuff from CPAN is not.

Also, we have the classic dev/test/production environment. When we upgrade perl (and CPAN modules) we first install in dev, sit and stew it, then promote to test, let simmer, and then if all is well, promote them to production. So although we don't CVS perl or CPAN modules we do at least have a fair amount of confidence in upgrades before they go into our final product.

-derby

Replies are listed 'Best First'.
Re: Re: Perl Management
by pinetree (Scribe) on Dec 19, 2003 at 14:31 UTC

    Similar to derby, I work with a dev/test/prod environment. As a developer, I can install modules under my own home directory (and since it's NFS mounted to all the dev machines see it everywhere). Perl is in a common location (/usr/local/bin/perl) and the modules under @INC are controlled by our Ops dept.

    Test is more strictly controlled (files must be changed in dev and migrated to test) and prod has very limited access.

    As a number of other posters have pointed out, you're best bet is to establish appropriate controls. If you can establish a dev environment where people can play with relative freedom you will have much less resistance to locking down your production environment.

    Oren

[reply]

In Section Meditations