In my last position we had a big/complex biotech information management system. We basically packaged everything needed to run the app into RPM files and distributed those. We built RPMs for RedHat Linux, OSX, and Solaris. The set included everything - perl itself, db server, apache, all the various CPAN modules we needed (packaged individually), etc.
in reply to How do manage your Perl application development, build, and deployment?
To install it, there was a script on a network drive that you could run. It would install the RPMs (which all install to /usr/local/<our_company>). If you wanted a dev environment, you pass a flag and the install script would check out our code over top of the version of our code installed by RPM.
It was clumsy at first but it fulfilled most (some?) of your requirements. Keeping all the packages updated was a major pain, but of course everything was in source control, properly tagged/branched/etc. (daily builds, release branches, etc.). Also, keeping a handle on the licenses of all third-party packages was a chore (for example, any GPL/LGPL software was off-limits and any commercial software needed a redistribution agreement).
We also had another project where we basically provided our perl code and a list of required software/modules and left it up to the customers to install them. I'm guessing the customers liked the RPM method better because they could install the system with 1 or two simple commands.