Why you should deploy your game with source control

One of the things that you may have noticed while following along with our tutorial is that each time we add a new feature, we start with a fresh checkout of the current version on our Google Code repository. This is for two reasons:

We get a completely ‘fresh’ version of our code – there won’t be any changes or differences between the versions that someone else and I am both using(assuming we checked out the same revision).
You should be keeping all of your changes in a repository – which is why after we have made our changes, they’re committed back.
Now, this is all well and good – but how are you deploying your projects?

Typically, I see people deploying their projects by opening up their favorite FTP client, connecting to their server, and uploading the files – and then afterwards, testing their changes to make sure they didn’t break anything. However, one of the other advantages of keeping things under source control is that you can check out your code from anywhere, as long as you have configured it properly. What this means is that you can also use source control to deploy your projects, making it much easier to keep track of which version of the game is currently deployed(and also do updates as necessary).

To begin with, you will need to have your source control repositories hosted at a location which you can access from your server – I prefer hosted source control, and typically use either Unfuddle or Beanstalk. Beanstalk is prettier, but Unfuddle gives you an infinite number of repositories for free(while Beanstalk will only give you one before you have to pay).

After setting up your repository and importing your project, you can do source control-based deploys by logging into your server and checking out a copy of your code(Subversion command shown):

svn co svn://your-repo-name.repohost.com /www/yoursite.com/game[php]
Once that command has been issued(and any required authentication has been done), you should have a brand new, fresh copy of all of your game’s code sitting on your server.

Now, thus far you may have been reading along and thinking “this is cool and all, but why would I ever need this? Deploying by FTP works fine for me.”. And, to be fair, if you prefer to deploy by FTP you can do that. But deploying from source control becomes useful after the initial deploy, for two big reasons(and one smaller one):

You can see exactly which version of your codebase you are currently running.
As long as you’re strict enough about it, the code running on your server will be exactly the same as any code you have access to; so if something goes wrong with the currently deployed version, you can retrieve the exact same code, and then sort the problem out.
Updating your game requires less bandwidth – as only the files that have changed will be downloaded to your server.
How do you figure out which version of your code is currently checked out? Just go to a directory with the checked out code inside, and run this command:

[php]svn info

Once you’ve done that, you should see a bunch of information about the version of your code that you are running the command on:

Path: .
URL: svn://your-repo-name.repohost.com/trunk
Repository Root: svn://your-repo-name.repohost.com
Repository UUID: 28cb6aaa-c762-4a6a-b8a9-6d82464dce74
Revision: 252
Node Kind: directory
Schedule: normal
Last Changed Author: Luke
Last Changed Rev: 249
Last Changed Date: 2008-11-20 14:08:31 -0700 (Thu, 20 Nov 2008)

And if you’d like to see the commit message for the revision that is currently checked out:

svn log --limit 1

You can change the value that you pass to limit(or remove it entirely) if you’d like to see more log messages.

However, as cool as all of this is, it doesn’t really get us to the nicest part of deploying this way: the ability to update and roll back files easily and instantaneously.

Let’s say that you’ve been updating little bits and pieces of your game, and you’ve noticed that combat.php has a bug in it that is currently preventing users from picking up items. Now, if you were using FTP to deploy your game, you would need to make the fix, upload the new file, and hope for the best. But what would happens if by fixing that bug, you introduce a new one that breaks things even more? If you’ve only been using FTP to deploy your game, there is no way to roll back. But if you’ve been using source control, rolling back to a previous version is easy:

svn up combat.php -r 26

Now, assuming that revision 26 had a working combat.php, your version of combat.php would revert back to the old, working version – giving you time to fix the bug. After you had fixed the bug, you’d be able to easily bring combat.php back up to date:

svn up combat.php

As you can see, deploying your game using source control gives you a lot more flexibility when it comes to rolling out updates to your game – you can use files from different revisions, keep track of which version of your game is deployed, and easily roll back to a previous version(or deploy a fixed version) if something goes wrong – without having to worry about accidentally over-writing anything.

Deploying with source control also makes it easy for you to keep multiple versions of your game available: for example, if you wanted to have a testing ground for new features, the version of the game that was currently playable by your users, and an older, legacy version – all you would need to do is check out different revisions of your code in each of the directories you were planning to put those versions in.

As you can see, source control is an extremely useful tool, even if you aren’t using it for collaboration – and when you have more than one developer, having source control in place is virtually the only way to collaborate with them effectively.