Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Machine replication

by set_uk (Pilgrim)
on Apr 10, 2003 at 11:16 UTC ( [id://249574] : perlquestion . print w/replies, xml ) Need Help??

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

I'm looking for pointers about replicating perl environments. Moving scripts from dev to prod is pain when having to install all the modules and possibly make external C libs again. Whats the quick way I should be following to avoid this pain?

Replies are listed 'Best First'.
Re: Machine replication
by Abigail-II (Bishop) on Apr 10, 2003 at 11:33 UTC
    Well, you only need to make C libs again if your production environment is different from your development environment. But that would not be a good idea. If your development and production environment are identical enough, all you need to do is tar up the perl tree in development, and drop it in production. Been there, done that, not a problem.

    Abigail

      When you say Perl tree. You mean everything under /usr/local/lib/perl5 right?
        That depends where you installed stuff. I typically install everything under /opt/perl. But you can tell Configure to install the binaries in /usr/local/lib/perl5, the manual pages in /usr/man/man1 and /usr/local/man/man3, and the libraries in /var/run. Now, I don't know how perl is installed on your system, so I cannot answer the question.

        Abigail

Re: Machine replication
by DrManhattan (Chaplain) on Apr 10, 2003 at 12:02 UTC
    Have you considered using CVS? I keep a CVS repository on my development server and update my production server from it. rsync and a shell script work pretty well too, but of course you don't get the revision control you'd have with CVS. E.g. when some new code goes horribly awry, you can easily retrograde from the CVS repository, because CVS stores not only the current version of your code, but also the previous revisions.

    -Matt

Re: Machine replication
by derby (Abbot) on Apr 10, 2003 at 11:55 UTC
    In addition to Abigail's comments, if the enviroments are exactly the same (and in my experience, it's better to have prod, test, and dev environments be the same), then rsync or rdist may be of use.

    -derby

Re: Machine replication
by v_thunder (Scribe) on Apr 10, 2003 at 14:15 UTC

    I use packages to manage all of my software, and that includes the perl programs I maintain. This doesn't magically let you have different development and production environments, but it does allow you to replicate your dev env with minimal pain (imho).

    My testing and production environments are updated using red carpet, although other solutions could be used instead (using apt, for example). On my development environment, though, I use the software I maintain unpackaged (but I use packages for its dependencies). So the only real difference is that in the dev env's @INC needs to include my development modules. I accomplish this with a little hack:

    use FindBin; use lib "$FindBin::RealBin/../lib";

    That means that @INC will include prefix/lib (e.g., /usr/lib) on a production system. If that's a problem, then you can comment out those lines before packaging the software for production use.

    This solution is more or less limited (in practice, not in nature), to systems with solid package management that can do dependency resolution. Meaning, if you plan to deploy software on e.g., Windows, then you'll need an additional package management layer, or a different solution.

    I'd be very interested in any comments, suggestions, or other working solutions other people might have!