tags:

views:

74

answers:

4

How can I apply code changes to my running website, if I have bug fixes or updates? The simplest way I can think of is to set up the same site in a different directory for testing the updates, and then put my website offline for a period of time to update files.

Is there a better way?

+1  A: 

You can run new version at different subdomain (or subfolder), and simply change domains handling after testing.

Riateche
This could still potentially lead to some data loss if a request is executed right at the moment when you switch.
Robus
Yes can be data lose , but mixing it with putting site offline ,May reduce the downtime very much ! I like the idea
Arsheep
+1  A: 

Nope, there is no better way (duh!)

Well, okay, there might be some better practises, as in you should have a seperate machine for testing purposes. But other than that, don't expect enlightment. You just take the site offline when the load is low (aka during the night) and change/replace stuff.

Robus
+6  A: 

Creating a copy of the live site is certainly a good step, applying changes to the copy before applying the same to the live site.

A common production environment would include a further set of steps.

  1. Run a local development copy
    Have a copy of your website running on your development machine. This requires that you development machine is running a web server, database server and, if necessary, a mail server.

    For PHP/Apache/MySQL environments, take a look at http://www.apachefriends.org/en/xampp.html.

    You can safely develop, break, test and change a your local development environment

  2. Source control
    Use Subversion, Mercurial or Git to keep your code under source control. Ensure your local development environment is kept under source control. Ensure your live environments are under source control. Develop locally, test changes and commit the changes back.

  3. Staging and live environments
    Maintain more than one 'live' copy - the actual live public site and as close a replica as possible. Ensure both are under version control.

    Once locally-tested changes have been tested, update your staging environment (usin your source control system) and test again. Once your staging site is stable, you can use your source control system to update your live site.

    There will not generally be much of a need to take the real live site offline to apply updates, but be sure that you can safely do so if needed.
Jon Cram
+1 Using source control ensures you can get the new code quickly, minimizing downtime. After that, you just need to hash out the details of testing code before deployment, how to make changes to the production database, etc. And yeah, these are really important, too!
grossvogel
+1 - very good advice. You can also consider using a virtual machine as your local development box. That way, if your server runs, say Debian, you can mirror the exact setup locally, even if you're running windows or whatever on your local machine.
timdev
+1 for using a VM as a duplicate of the production environment. A good Physical to Virtual tool like VM WAre really helps this process out.
Jason
+1 Create a staging site at some url like testing.mysite.com and when it's ready to go just switch the virtual host the the new directory or move(mv) the files. Or it may be easier to update with version control but be careful not to overwrite config files with things like database passwords.
Keyo
+2  A: 

Jon Cram answered this really well, but I think there's a few more things that are really important when maintaining development environments:

  • Evnironments: Make sure the 2 environments you have are as close as possible to each other. If you're running PHP 5.1, MySQL 5.0, and Apache 2.2 and RHEL in production, make sure you're using exactly the same versions of everything in your sandbox.
  • Data: Make a copy of your database, and use that. DON'T EVAR write or test code against data that's in production. One DELETE without a WHERE and you're in trouble. (You have a backup, right?)
  • Configuration: Keep all your variables for connecting to databases, email addresses for support, etc in their own file. This way, you can just swap out connection parameters in your different environments without actually altering code. Also, I've found it's helpful to commit it separate from your code.
  • Build scripts: It's helpful to have a command line script that will handle applying all the changes to your site. It can as simple as svn update or complex enough to require it's own app and library. See http://phing.info/trac/ for a good example.

Also (shameless plug), here's a post I write a while ago on the importance of sandboxes: http://chr.ishenry.com/2010/02/22/sandboxes/

Chris Henry