|laziness, impatience, and hubris|
in my current project (not a web app, system programming and automation), we use the following way to develop, test and do the roll out.
CVS: will soon be replaced by Subversion
UML: we chose the Rational ones from IBM, and TopCased as an Eclipse plug in for the developers who don't have licenses for the Rational stuff (only for documenting).
Eclipse (from YOXOS) with EPIC for Perl support, an integrated CVS (soon SVN) client (is as easy as tortoise), perltidy for formatting, and a lot of eclipse templates. It wasn't easy for me to switch from emacs (my favorite editor) to eclipse, but using the same platform independent tool for all developers is a big pro in my eyes. We just evaluate Jazz which looks very interesting.
Coding Standards: we use a subset of "Perl Best Practices" (those parts which make sense) and several enhancements
Perl and add ons: to get a standard environment, we use pkgsrc for Perl, libraries and some applications
Packaging: we use RPM for Linux, InstallP for AIX (and soon MSI for windows) and developed a little tool who does the packaging for us. The roll out is done in several stages, from develop (2 servers) to test (8 servers), to acceptance/integration test and then into production (about 200 server). We use a lot of automatic tests for step one and two.
Perl-Modules: lot's of them, but a list of them might not be helpful for you :-)
Bugzilla: for Bugtracking, and the eclipse plug in mylin to use most of its features from eclipse.
Update: I forgot bugzilla, and fixed some spelling errors...
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v126.96.36.199.11.32"
In reply to Re: On the scaleability of Perl Development Practices