How to optimize upgrading web application?

I mantain a custom PHP application (build for me) that is hosted in a web server. Sometimes I add new features or repair bugs, and after test in local I upload the changes to the web server. It's not a critical application (is a game), but the most of the time there are some people connected.

The steps that I make to upgrade the application:

1. Access via FTP (Filezilla)
2. Upload a .htaccess file that redirects all the people (except my IP) to a mantain.html file
3. Check that access is denied for other IP except mine.
4. Backup old code
5. Upload new code
6. Go to PhPMyAdmin
7. Backup DB
8. Execute scripts for the DB
9. Test that all 开发者_StackOverflow中文版works fine (if not -> revert the backups)
10. remove .htaccess file

I usually spend an average of 30 minutes doing these steps, and I'm wondering if there is any way to optimize, automatize or doing something to spend less time. Also I know that if I can automatize some steps there are less prone to have errors.

Several other answers suggest PHP-specific deployment tools, but being as I'm not very familiar with PHP, I'll offer some general tips. These suggestions may be redundant by some of the other tools already suggested, though.

First off, don't upload a new .htaccess file every time--just have two of them on your server. Perhaps call them .htaccess-permanent, and .htaccess-maintenence. Then create a symlink to the one that ought to be active. Then once you've tested that access is properly denied once, you don't have to do this manual testing phase every single time you do an upgrade.

I'd also write a shell script to do most everything for me. My new work flow would look like this:

1. Upload new code to server in a directory called new/
2. Log in to the server via shell, and execute the upgrade script
3. Test the new site
4. Run upgrade-finalize

The end.

Now for the interesting part, the upgrade script will do this:

1. It will delete the .htaccess symlink, and re-create it, pointing to .htaccess-maintenence.
2. It will copy the current code in current/ to backup/
3. It will back up the DB, using the exact same commands that PHPMyAdmin uses
4. It will move the contents of new/ (which you just uploaded) to current/
5. It will execute the scripts for the DB

And the upgrade-finalize script will simply:

1. Delete the .htaccess symlink, and re-create it, pointing to .htaccess-permanent once again

The only possibly tricky part here will be getting the exact commands that PHPMyAdmin uses to back up your database, but it's probably a simple mysqldump command, and you can probably get that info from PHPMyAdmin or some logs, or something. Sorry, I don't know more about PHPMyAdmin to help in this specific area.

Look into a deployment tool like Capistrano that allows you to automate those steps.

I usually spend an average of 30 minutes doing these steps, and I'm wondering if there is any way to optimize, automatize or doing something to spend less time.

There are many ways. For starters, steps one through eight can be done in a single shell script. You could checkout Phing, an automated deployment system. Also, you might want to delve in continuous integration for even more control over how and when the software can be deployed.

Doing this manually is, like you say, asking for trouble.

For starters, you could upload your files into a new webroot and when done, switch over the DocumentRoot in apache, leaving it available during the copy process. For any shared files you could use a symlink to a common folder (eg, uploaded images etc)

You could probably take the backup during operation as well if you don't care about consistency in the database. For migrations that doesn't "break" the functionality, you could also migrate it and test it on your new webroot with another hostname if consistency isn't a problem.

The best option is always to use multiple webservers so that you can take one offline for testing while the other one is operational, but you will still have problem with consistency, however I assume that is not an option since you don't mention it.