Finding the right deployment strategy takes some practice. I'll tell you some basics of how we do it at http://plusthree.com/, for a fairly large Perl application.

First, we keep the code in Subversion. In addition to some obvious benefits of avoiding overwriting each other's work and keeping long-term undo, it's the only way to deal with needing to keep a released version working with occasional patches while you build a new version. This is done with branches.

Next, you need to make a release somehow. We have a script that build release packages. They aren't much more than a .tar.gz file, but some things that are only relevant for development are left out, and care is taken to avoid over-writing config files.

We move that to our server, where we unpack it and run an automated build script that builds all the included CPAN modules. Then we run upgrade scripts which make any required database changes between releases.

We include the CPAN modules in their normal compressed state and automate the whole unpack, Makefile.PL/Build.PL, install business. We install them into a local directory, not the site_lib on the machine, and point our apps at that directory. This means that we always know exactly which version of a module we're using and never get burned by a change in a module's API on an upgrade.

There have been cases where we needed to modify a CPAN module. In that situation, we move it to the source tree, at least until a later version that no longer needs our changes is released. (And yes, we share our changes with the authors in these cases.)

Since we're dealing with dedicated hardware, not a cheap shared host, we control the environment as much as possible. We build our own perl, so we can count on knowing the version and the compile options and not be surprised by a special Red Hat patch or a missing Scalar::Util feature. We also install a specific version of the database, so we know what to expect from it too.

If you're building something to run on shared hosts, or your project is small, then this may be overkill for you. It's been really helpful for us though. You can see most of this in action in the Krang CMS project, which shares many of the same build and deploy approaches.