R. Keeping Your Local and Remote Sites Synchronized
The point of a test site is to have a place to experiment or develop new content without impacting your users or giving away your latest gee-whiz before its time. But it is also important to make sure that you always have a good working version of your live site on your test site.
Let's ignore, for the moment, that in an "ideal" world you will have a staging site which is always identical to the live site and nothing goes live without being staged.
There are two basic techniques for keeping your sites synchronized:
- Manually making sure that the content of the two sites are the same.
- Frequent uploads or downloads of database back ups.
The first technique is quite time consuming and it's difficult to keep user comments on your test site. It also relies on your memory to know what's been changed, unless you update both sites at the same time. If there are things that are dependent on other things (sorry for the technical terminology), you have to be careful that you update them in the right order so that your random visitor doesn't break something.
The second technique allows for user comments to be downloaded to your test site. From there they can be incorporated into the content and deleted, or left as is. You just have to be careful that you don't lose new, experimental, or incomplete content that hasn't been put onto the production site yet.
Which is better? I can't answer that question for you. You need to weigh the risks and benefits and decide that for yourself. Personally, at my age and with my memory, the second technique is probably better for me, at the risk of losing something not yet uploaded. I also have the bad habit of updating things on the live site and not bring the change back to my test site.
To read more discussion on this topic you can read this thread in the Developer mailing list and this post by Larry Garfield (Crell).
Testing on local server or remote server
It is sometimes good idea to create your test site on the same server as your live site, especially if you cannot guarantee that your local test system is the same set-up as your remote live system. For example, if your live web server still uses MySQL 3.23 with Apache 1.1 running on Linux but your local test site uses MySQL 5.1 running Apache 2.2 on Windows you cannot always guarantee that Drupal or the modules and themes you install will work on your remote server if they work on your local test server due to version incompatibilities.
I usually do this by creating a test directory on the same server my live site is using. I password protect that folder so that it is inaccessible to the public (I use .htaccess to do this—see the Apache documentation to see how it is done or check your server control panel for a short-cut).
It is much better to use a different database for testing so there is no chance of your test site corrupting your live site's database; but if you cannot do that you will have to use a table prefix (such as "test_") to differentiate between test and live database. Be sure to configure this correctly, though, in your /sites/yoursite.com.testfolder/settings.php file.
You could just make sure that the software running on your local server is the same as your remote server but if you have accounts with several different hosting service providers or are doing work for several different clients it is sometimes impractical to have multiple versions of software on your local test system to accommodate this. There is peace of mind in knowing for sure that the installation and modules that you are testing on your test site will definitely work on your live site also.
SVN or CVS
Using a tool like SVN or CVS can help make the process of keeping local and live builds sync'd correctly. These are especially useful if you are building a website with multiple developers working at the same time. Also, the beauty of these tools is that they can keep archived versions of the files to go back to should anything be wrong.
Useful Links:
CVS Homepage
Subversion Homepage
Windows SVN Client
Mac SVN Client
Eclipse SVN Plug-in