Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Thanks for this, I would love to hear more similar stories from other people.

    In our case, we are still trying to be perfectionists and maintain >300 in-house .deb packages and several hundreds of hand-builded cpan packages as well.
    Actually, in our case our "application" consists of many various scripts and daemons, working on different hosts and clusters, so it is impossible to pack everything in one package anyway.

    I've been dreaming for a long time about fully-automated cpan-to-deb (and cpan-to-rpm) bui

    • by Alias (5735) on 2010.07.20 20:35 (#72190) Homepage Journal

      We have something similar of course, web cluster + application server + integration server + internal web server, but we've found that it's easier to just deploy the whole project to all the servers, and only start up the parts that are relevant.

      For example, the internal and external websites share the same web application code, but the controllers and dispatch paths are only loaded into memory if that "profile" is enabled in configuration for that server.

      So while the public facing web servers do theoretically have all the application server and internal website code on them, we can be sure they will never be loaded and run.

      That said, we aren't a public facing website and we're just a front end to an ERP monstrosity sitting behind us, so we can take some minor liberties in that regard.