in reply to What are all the possible ways to deploy Perl code on multiple servers?
I've done it the following two ways at different jobs.
1. We packaged perl and all deps, plus all cpan modules (and their deps) from source as RPM files that would be built on 3 different operating systems (rh enterprise linux, solaris, and osx). We shipped the RPMs to our customers when a release was cut (either on CD or electronically). It was built using make so if you changed/updated any of the package sources it would recompile it plus everything that depended on it. It was a hassle to maintain at first (I inherited it from a previous employee) but once I worked out the kinks it was very reliable and our customers liked it. It made upgrades pain-free (from their perspective).
2. At my current job we decided to use the "standard perl" on ubuntu 10.04 LTS. I mirrored the ubuntu repo and we use apt to manage all the packages across our servers. Basically we programmed against what's in the official repo and we only update our mirror after we test any package changes. The drawback here is that there are some modules that aren't in the ubuntu repo or that are too out of date to be useful. In these cases, I build custom .deb packages and put them on a separate repo (which is also included in each server's sources.list). Then there's a "my_dependencies.deb" package which gets installed that lists all our custom packages plus all the ones in the ubuntu mirror that we need. It's been working very well so far and it's much less work than maintaining all the packages ourselves.
Granted, "standard perl" on Ubuntu 10.04 LTS is out of date but we don't really miss any of the new features.
1. We packaged perl and all deps, plus all cpan modules (and their deps) from source as RPM files that would be built on 3 different operating systems (rh enterprise linux, solaris, and osx). We shipped the RPMs to our customers when a release was cut (either on CD or electronically). It was built using make so if you changed/updated any of the package sources it would recompile it plus everything that depended on it. It was a hassle to maintain at first (I inherited it from a previous employee) but once I worked out the kinks it was very reliable and our customers liked it. It made upgrades pain-free (from their perspective).
2. At my current job we decided to use the "standard perl" on ubuntu 10.04 LTS. I mirrored the ubuntu repo and we use apt to manage all the packages across our servers. Basically we programmed against what's in the official repo and we only update our mirror after we test any package changes. The drawback here is that there are some modules that aren't in the ubuntu repo or that are too out of date to be useful. In these cases, I build custom .deb packages and put them on a separate repo (which is also included in each server's sources.list). Then there's a "my_dependencies.deb" package which gets installed that lists all our custom packages plus all the ones in the ubuntu mirror that we need. It's been working very well so far and it's much less work than maintaining all the packages ourselves.
Granted, "standard perl" on Ubuntu 10.04 LTS is out of date but we don't really miss any of the new features.
In Section
Seekers of Perl Wisdom