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:

  1. 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).
  2. 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

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):

  1. You can see exactly which version of your codebase you are currently running.
  2. 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.
  3. 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:

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.

Wish there was more?

I'm considering writing an ebook - click here.

.

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Tags: , ,

Thursday, November 27th, 2008 server
  • Jacob Santos

    I usually, do automatic deployments with either after a commit or a duration of time. The automatic, with a commit script, works great, since you'll always have an up-to-date copy on the live server. If there are permissions problems with the commit script, then you can do it with a cron job.

    The reason I do it this way, is that I'd already have tested the changes I made before committing, so every commit should already be stable. The second reason is that I don't have to shell or remote into the server to update.

    I don't want to have to give my developers access to shell and so by doing it automatic, I relieve that requirement. All work that I do uses version control, but Subversion isn't always easy for novices.

    It is very basic in that you do the same steps over and over again, but there are catches and if you've never had a conflict, then you'll be confused as to what you have to do. It is worth learning though.

  • now i switched blackswordrpg from cvs to svn :)

    With unfuddle i can work on the game wherever i am

  • Yup! That's exactly why I do all my deploys from source control now - even
    if I'm not at my primary development machine, I can still pull down a copy
    of the source code, make my changes, and deploy it.

  • Scion

    just adding my 2c

    I wonder if rolling back a single file to a previous version.....(in production at least) could be dangerous in of itself....your app is likely to have a number of interdependancies and if you roll back to a previous version of a single script you may find that everything is still not working because of inconsistant interdependancies.

    I prefer to tag the repository with a build number and then checkout the tagged revison of the whole project....

    But on the whole i agree completely....if your not using source control....your not doing yourself any faours.

  • Hi Paul,
    You're definitely right about rolling back single files causing dependencies
    issues - and checking out based on a tag is definitely a good way to work
    around that problem.

  • Thanks, very useful and interesting article.
    I created an account on Unfuddled, what about a related article on installing a wamp/lamp environment on a usb keys?

blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames