Let's say I have an online game up and running, and its version 1.0.
I keep developing on staging server and bring new features into the game. The staging server is a separate server from the live server. (I am sure most of the people do it this way)
OK. I finish the new version 1.1. Now what is the best practise to do online game server upgrade?
Let's assume it is a simple game server PHP+MYSQL. So there are new php scripts or changed scripts, and new mysql tables, columns or modified columns. I hope not to do it manually - Manually do the same changes one by one on the live server. That's ugly and easy to make mistake, and have to remember every single changes you did.
Another way I can think of is make the staging server to be live, and import all existing database data over. I don't like it, seems mistake can happen any time.
What is the best way you can recommend?
Version Control (Git)
You should have a git server on the live server, as well, as on your testing/stage server. You would make commits for changes you make, then you would "push" those commits/changes to the server. Once your test server works, you would push it to your live server.
Migrations
Most modern PHP frameworks offer this feature. Basically, you would describe your database schema within code. With Laravel, you would run: artisan migrate or something which would push the schema to your database.
With only one database and one web server you might want to stop the public from accessing them until it's updated, this is mainly for the database, and would only last a few seconds but would prevent any errors while migrating. A simple git post hook would do the trick. There is a ton of info online about this.
I've heard that SharePoint makes the front-end support the old and the new database. Then you first update all front-end code and use the old database. After all users use the new front-end code, update the database. Once the upgrade is completed, you can remove support for the old database and do the same trick again for the next version.
This way you have minimal downtime with a load-balanced front-end.
Maybe they made it sound easier than it is, but I like the principle.
Create a database upgrade script. Preferably generate one using a tool.
Build a release package for version 1.0 if you have not already done so. Build an upgrade package plus deployment script for version 1.1 which will patch your production version from 1.0 to 1.1
For inspiration on how to update an existing deployment you could look at How Wordpress upgrades:
Recreate your production machine on your staging environment using the 1.0 release package and test the deployment of your upgrade package there until you are satisfied, before you go live.
Backup production, upgrade production.