Continuous Integration

Continuous Integration – The Crucial Parts

I’ve gone over what the main benefits of Continuous Integration can be to a project, so it makes sense to move onto the various processes used at Blitz Arcade and how these benefits actually come through.  As I mentioned, CI process can come in many different shapes and sizes, but most will have the following process in common (even if they don’t use the same software or ideas).

 

Version Control Software

The basic lynchpin of any integration process is solid version control software, and with that I don’t just mean source control software but all the other assets that are used in the build process.  This can include models and textures, scripting files, sound packages or anything else that is needed to build the game.  Without version control software, how do you get the latest copies of all the game assets or the source?  Copy them off a shared network folder?  E-mail them to shared locations?  Most people will know that simply doesn’t work and if you don’t I’m sure you will learn why soon enough.

It might seem obvious and I would expect even one-man development teams to be using something like Subversion for their code base at the very least, especially with the ease that these systems can be set up, but that it not always the case.

At Blitz we use Subversion for all our source control needs as it’s solid, mature, mostly reliable and is totally free.  Some people prefer Perforce, some people are starting to see the merits of Git, some people might even use SourceSafe (but at least they are using something!).  We also use a variety of SVN 3rd party tools, namely TortoiseSVN and AnkhSVN.

For asset control we use our custom BlitzTech asset control system which allows us to associate a large amount of meta data with each asset and to review the whole history of the individual files.  But even though most source control systems are not really set up for binary data you can still hook the process together if you don’t have access to anything else.

By using these tools we can back track to any point in time and see the project as a whole, get the most up-to-date content that is required for the entire game, and review changes across every asset in the game, all with just the click of a button.

CruiseControl.Net

CruiseControl.NET is a free Automated Continuous Integration server that hooks directly into a set of source control repositories (in our case per project Subversion repositories) and automatically kicks of a build process every time a change to the repositories is detected. This will then build the project for a set of platforms and configurations, meaning that on every check-in our example project – Super Space Fighter VII- will be built on Xbox360, PS3 and PC and will usually build all debug, release and master builds.

Since this is always done on a specific Cruise Control machine, we can guarantee that the builds are being done in the same environment with the same set of conditions every time, regardless of who last checked in their work.  So when it builds on one person’s development machine, but not the Cruise Control machine, then there is something the original developer needs to fix before anyone else can get latest.

Cruise Control also provides a variety of feedback mechanisms to help the developers get the most of the system.  The CruiseControl.net system tray allows simple notifications if a build breaks on a check-in, which then allows the user to see the build output and to find a solution before checking anything else in.  Since this is constantly running the background developers are always informed when a build breaks.

So at the most basic level, we have a system that is totally version controlled, meaning we can step back to any point in time of the projects life cycle, and a project’s code base that is continually built throughout the day, meaning we now know if we even have a project that compiles from the off.  While this is a great start, Cruise Control as it stands still has problems, namely the time is takes to build a project (our example project has 9 different combinations to build) and that fact that broken builds can still be left unchecked if the developers miss the notifications.

In the next part I’ll cover how we have extended Cruise Control to improve the notifications, speed up the whole process and to track the various build stats that are happening throughout the day.

1 thought on “Continuous Integration – The Crucial Parts”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s