Game Development Reference
In-Depth Information
Scripts Can
'
t Update Themselves While They Are Running
If you
ll realize that the build scripts themselves should
be checked to make sure they haven
'
re paying attention, you
'
t changed. If the build script is running,
how can it clean itself off the build machine and get itself from the source code
repository? It can
'
t, at least not easily. If you standardize your projects with a
single directory structure, it
'
s better to create a master build script that works
for any project. Project-specific build commands are put into a special build
script that lives in the same directory as the project files. The master build
script should only change when the build process for every project is changed
'
something that should be extremely rare.
A nightly build process is actually trivial to set up if you have your automated build
working just set up a scheduled task on the build machine. For Windows, you can
create a scheduled task by going into the Control Panel, run Administrative Tools,
and run the Task Scheduler. The wizard will take you through the steps of defining
when and how often to run it. If you happen to be a Linux person, look up the cron
command. Usually, it
s a good idea to copy the results of the build to your network
where everyone can grab it.
'
Milestone Build
Milestone builds add more steps to the beginning and end of the build since they
involve branching the code. They also involve an approval process that takes days
or weeks instead of minutes, so the build process has an
open,
a
create,
and a
script to manage the branches and make sure that any changes that happen
during approval get back into the Trunk branch.
close
No Build Automation = Madness
At Origin Systems, we didn
t do anything special for milestone builds on the
Ultima projects. Some unlucky programmer, usually me, launched the build on
his desktop machine, and after plenty of cursing and a few hours, the new
version was ready to test. The other programmers kept adding features and
bugs as fast as the test team could sign off old features. New code and
features would break existing code
'
stuff the test team approved. The bugs
would pile up, and it was difficult to figure out if the project was making any
progress. To minimize the pain of this process, it was usually done in the
middle of the night when most of the developers had gone home.
The projects I
ve been on since then were entirely different, mostly due to
ditching SourceSafe and using branches. Our source code repository, Perforce, had excellent branching
and merging capabilities. The programming team resisted at first, but they quickly saw that milestone
builds were linked directly to their paychecks. A few milestones later, everyone wondered how we ever
developed projects without branching.
'
 
 
Search WWH ::




Custom Search