Builds are made by hand.
One person knows how to package the game, and their machine is the build server.
Builds anyone on the team can trigger
Unreal Engine build pipeline automation
A build that only one person can make puts every milestone at risk. We set up CI that compiles every change, packages the game every night and tells the right person when something breaks.
<BuildGraph xmlns="http://www.epicgames.com/BuildGraph">
<Option Name="ProjectName" DefaultValue="MyGame" Description="Project to build"/>
<Property Name="ProjectFile" Value="$(RootDir)/$(ProjectName)/$(ProjectName).uproject"/>
<Agent Name="Nightly Win64" Type="Win64">
<Node Name="Compile Editor">
<Compile Target="$(ProjectName)Editor" Platform="Win64" Configuration="Development"/>
</Node>
<Node Name="Cook and Package" Requires="Compile Editor">
<Command Name="BuildCookRun" Arguments="-project=$(ProjectFile) -platform=Win64 -clientconfig=Development -build -cook -stage -pak -archive -archivedirectory=$(RootDir)/Builds"/>
</Node>
</Agent>
</BuildGraph>Signs the pipeline needs work
The nightly is red more often than green.
Nobody knows which change broke it, so nobody fixes it.
Fast feedback on the change that broke it
Iteration is slow.
Full rebuilds and long cooks eat hours every day.
A shared DDC and distributed compiles
What we set up
CI setup
BuildGraph scripts and build agents on Horde, Jenkins, TeamCity or GitHub Actions, depending on what your team already runs.
Cook and package
Automated cook, stage and package for each platform you have SDK access to, and each configuration, with versioned build artefacts.
Automated tests
Compile and content validation on every change, plus Gauntlet and functional tests on packaged builds.
Iteration speed
A shared derived data cache, Unreal Build Accelerator or other distributed compilation, and shader compile tuning.
Source control
Perforce streams or Git LFS set up for game-sized projects, with branching that matches how you release.
Crashes and distribution
Symbols stored per build, crash reports routed to your tracker, and uploads to Steam beta branches or an internal launcher.
Who builds it
See the whole team.
Andrew
Build & Tools EngineerDesigns the pipeline, writes the BuildGraph scripts and sets up the agents.
Jordan
QA & Test Automation EngineerAdds the automated tests that run on each build.
In practice
What a pipeline engagement looks like
We start by timing your current build end to end: sync, compile, cook, package and upload. That shows where the hours go and which step fails most often.
The first automated path is usually one platform in Development, built every night and on demand. Once the team trusts it, we add per-change compile checks, tests on the packaged build, shared caches and notifications that name the change that broke the build.
Everything lives in your repository as BuildGraph scripts and agent setup notes, so your team can read it, change it and run it without us.
Build pipeline FAQ
Do we need Horde?
No. Jenkins, TeamCity or GitHub Actions with BuildGraph work well, and we usually build on what your team already knows. If you want Unreal Build Accelerator to spread compiles across machines, we set up Horde for that part.
Can you use our existing build machines?
Yes. We can use your machines, cloud agents or a mix, and we document the setup so your team can maintain it.
How long does a first pipeline take?
It depends on the project and the state of the build today. Mapping your current build, the first step, gives you an estimate before any build work begins.
Related services
Start a project
Tell us about the project
Send us the engine version, where the project is and the work you need done. We reply within two business days with who we would put on it, or tell you it is not a fit.
Prefer email?hello@moduleforge.studio