一家位于欧洲的中型工作室，其构建一直靠资深工程师在本职工作之余维持运转。
工作室
- 中型工作室，欧洲
- 没有专职构建工程师
- 托管运行器
- 试点
之前
构建维护没有负责人。一次 SDK 更新、一次引擎升级、构建机磁盘爆满：每一件都落到某位资深工程师头上，占用的是本该用在游戏上的时间。由于这些工作分散在不同的人和不同的周里，没人说得清到底有多少。
架构
01触发
源码控制每次推送
定时计划每晚运行，也可按需运行
02编排
托管运行器Unreal、SDK 和引擎保持同步
游戏感知缓存只重新构建改动的部分
03并行构建
平台流水线同时启动，并行构建
烘焙与打包按平台进行，基于同一提交
04交付
构建洞察状态、失败、耗时和趋势
修复建议错误旁给出文件和行号
Slack 与 Teams结果实时推送
他们如何使用 SpeedrunCI
01
先量化
试点首先让维护工作变得可见：什么出了问题、谁修的、花了多长时间，让工作室看清自己为此付出的工时。
02
无需维护构建机
构建迁移到 SpeedrunCI 的托管运行器上，这些运行器已配好正确的 Unreal 环境。SDK 和引擎版本由 SpeedrunCI 保持同步，而不是靠资深工程师。
03
只构建改动的部分
游戏感知缓存会在多次运行之间保留编译后的代码、烘焙后的资源和派生数据， 因此一次改动只会重新构建它涉及的部分。
04
状态与趋势集中一处
构建洞察展示状态、失败、耗时和趋势，制作人无需询问工程师就能了解构建进展。
05
错误旁直接给出修复
构建失败时，会指出出错的步骤和提交，并给出修复建议，指明需要查看的文件和行号。
06
结果直达团队工作的地方
构建结果会实时发布到 Slack 或 Microsoft Teams。
改变了什么
先量化，再交还。构建维护现在由 SpeedrunCI 负责，资深工程师的时间回到了游戏上。
托管运行器维护工时已量化