I'm going to make some general recommendations here from my experiences (both bad and good) in managing builds and deployments.

First, if you are running any kind of a production system, you need version control. Not just because it makes it easy for the programmers, but because it makes it easy for operations to roll back changes if they're bad. With version control you have the option of being able to precisely undo or redo any change you've made - this can be really handy if (say) you've added a new feature, which works fine, but messed up a configuration setting. With version control, you can back out the bad stuff and keep the good (most of the time anyway). Git is great; we're using Mercurial is also very good. Subversion is an option, but git or Mercurial will probably end up working better for you. Even rcs is better than nothing for a solo developer.

Second, you need strongly to consider a staging system. This allows you to pretend you pushed the code to production and then try it. Often you can manage this with a virtual machine if you don't have enough servers to let you try things live; you may need to create a test database (for example) to make sure you have all te resources you need to run. I've had pretty good success with VirtualBox - it's easier to get running than Xen or VMWare, at least for me.

Third, you need a test suite. Unit tests and integration tests which are run when the build is done, and "live" tests that hit the server and verify that it's doing what it should be doing. Selenium is a very useful tool for testing web interfaces. If you have a REST server, you may be able to use WWW::Mechanize to test the backend. If you also have a custom client, Mojolicious::Lite is a grand way to put together a mock server that can send the data you expect, as well as fail predictably so you can test your client's error handling.

If you have all these, then you can consider using a continuous integration server (I like Hudson for its flexibility and easy of deployment) to monitor your version control repository and automatically check out, build, test, and deploy to staging whenever a checkin is done (or on a fixed schedule, depending on how quickly the codebase is changing - you of course have the flexibility to only deploy once a day, etc.).

The key to good deployment is to have a simple (hopefully scriptable) deployment process. Every manual step in a deployment adds to the possibility of a failure or error. Staged deployments will, most of the time, allow you a simple way to check your deployment before you push it live.

One final thought: if you can manage it, try to create a design which integrates directly into the OS on the deployment machine as little as possible. Use local::lib, or build your own Perl, to ensure that OS updates don't end up breaking your code. In addition, if you avoid integration, you may be able to use a "twinned" deployment: two copies of the software, one the "live" old version and the other a not-running new version. You can then shut down the old system and bring up the new (barring database migrations, for instance) without problems.

Anything that could destroy data or transform it in a non-recoverable manner requires extra steps to back up the pristine data and restore it if necessary. You must test this prior to the real deployment to make sure you're not crossing a line of no return. There's nothing worse than migrating to a new setup only to find you have a really bad bug that you didn't find in testing, with no way back to the old system!

I seem to have written an entire essay on this. Perhaps I should copy this over to Q&A or Meditations...