|
 Features
Automated Build and Test Systems for Games
 Requesting Builds
First, we needed a way to allow clients - the developers on the
team - to request the build servers to do work daily. Although
we do run many builds on a nightly basis automatically, it is often
important throughout the day to deploy a new version of the game
executable to the rest of the team - for example, when a programmer
implements an urgent bug fix. Given that requirement, we needed
a way to service requests at any time. The current solution in
use is a paired .NET client and server application. Using the C#
language and the .NET framework for tool development has proven
quite efficient. If you haven’t already looked into the language
and framework, it is easy to use, powerful, and has increased our
tool production efficiency quite a bit. The build client application
is a simple, data driven GUI that allows developers to pick from
available build types and add them to the build queue. It also
shows what is currently in the build queue, and allows users to
cancel queued builds in case they made a mistake or wanted to cancel
a less urgent build request to allow an important build to start.
Example of the build client request application at work.
Handling Build Requests
A build “mast er”server receives the incoming client
requests. This application is in charge of brokering individual
build requests and sending them to servers that can fulfill them.
The master server knows each build server’s capabilities,
because each build server registers itself with the master server
and immediately tells it what types of builds it can fulfill. Again,
this is totally data driven; new build types are simply added to
an XML file, none of the client/server applications need to be
recompiled. The master server is responsible for load balancing
requests between servers. Distributing builds in this way allows
us to have, for example, a build machine dedicated to compiling
executables and another for bundling source assets into runtime
engine data. The way that work is split between servers can easily
be changed to whatever maximizes build system throughput in each
individual project.
By having an independent build server which only contains the latest set of data, as opposed to developers doing builds on their local machine to be released to the team, we ensured that no stale or debug data or code entered the official build. Without a system that separates the machine making the official builds from the developers it is difficult to guarantee this.
Build server capabilities are set per build server in an external XML file that defines what the specific server knows how to build. This is then communicated to the master server.
|
|
|
|
|
Previous