Version control is an essential tool when it comes to maintaining your code and properly tracking filesystem changes. In this quick tutorial, I'll show you how to update a Drupal module in a subversion integrated environment using rsync. Since simply copying the contents of a new module update on top of your current directory structure is a bad idea (since it will NOT account for file deletions), rsync is a great solution for syncing module update changes. NOTE: it is a bad idea to update a module in a production environment without proper testing; this code assumes you are working in a development environment.

The first step is to download the latest (and in most cases, stable) package for the module you'd like to update to a directory outside your drupal path. For my Drupal installations, I browse to the Available updates page (admin/reports/updates) and copy the URL from this page. Next I go to my shell, use wget to fetch the package to my home directory, and unpack the file:

Now you can run the rsync command to apply the filesystem changes to your Drupal module directory. You'll have to update the paths listed below to match your filesystem and Drupal installation.

If executed properly, you can change directory to the module you are trying to update and run an "svn stat" command to see what has been updated. NOTE: the below output is simulated to show common svn status changes.

At this point, you should see a list of all the files that have changed with this module update. You can now run the update.php script in your development environment and verify the changes are working properly. If everything is working properly, you can commit the module update changes...

Now, you can safely deploy the module changes to your production environment (svn update), run the update.php script, and ensure everything is working properly.

It's important to treat content management systems like any other application and segment development, test, and production. Before adding content and attaching files to nodes, it's very important to set the file system path correctly and establish a deployment procedure.

One way to make the transition from development to production a smooth process is to use the same directory for your files. If you are using one Drupal installation for each project sites/default/files will work fine. If you set your file system path specific to your development hostname (for example: site/dev.HOSTNAME.com/files), you'll be in trouble when you transition to a new hostname.

Here's an example process to show how you could transition a site from development to test (or any other environment).

1. Migrate your MySQL database to the new server. Each environment should use its own database.

2. Copy your Drupal installation to the new server. Hopefully, you're using subversion (or some other version control software) to deploy these files.

3. Create a new folder in your sites directory for the new hostname. Copy your existing settings.php into the new folder. Edit this file and update the MySQL connection string to match your new database, user, and password.

4. Create a new Apache virtual host for your new hostname and direct DNS accordingly.

Now, if DNS has been setup for your new hostname, the site should be up and running on the new server with a new hostname.

Additional thoughts: It's very important to avoid hard coding hostnames and absolute paths in your links, code, and themes. I promise, it will make your deployment process a nightmare.