ヨーロッパの中規模スタジオ。そのビルドは、シニアエンジニアたちが本来の仕事の合間に支えていました。
スタジオ
- 中規模スタジオ（ヨーロッパ）
- 専任のビルドエンジニアなし
- マネージドランナー
- パイロット
導入前
ビルドの保守には担当者がいませんでした。SDKのアップデート、エンジンのアップグレード、ビルドマシンのディスク容量不足。そのたびにシニアエンジニアに仕事が回り、ゲーム開発に充てるはずの時間が削られていきました。作業が複数の人と何週間にもわたって分散していたため、その量がどれほどなのか誰にもわかりませんでした。
アーキテクチャ
01トリガー
ソース管理プッシュのたびに
スケジュール毎晩、またはオンデマンド
02オーケストレーション
マネージドランナーUnreal、SDK、エンジンを常に同期
ゲームを理解するキャッシュ変更部分だけを再ビルド
03並列ビルド
プラットフォーム別パイプライン同時に開始し、並行してビルド
クック＆パッケージプラットフォームごとに、同じコミットから
04配信
ビルドインサイトステータス、失敗、所要時間、トレンド
修正案エラーの横にファイルと行
SlackとTeams結果をリアルタイムで
SpeedrunCIの活用法
01
まずは計測から
パイロットは、保守作業を見える化するところから始まりました。何が壊れ、誰が直し、どれだけ時間がかかったかを記録し、スタジオが負担していた時間を把握できるようにしたのです。
02
保守するビルドマシンはゼロ
ビルドは、適切なUnrealの環境が整ったSpeedrunCIのマネージドランナーに移行しました。SDKとエンジンのバージョンは、シニアエンジニアではなくSpeedrunCIが同期を保ちます。
03
変更した部分だけ
ゲームを理解するキャッシュが、コンパイル済みのコード、クック済みのアセット、派生データを実行間で保持するため、変更があっても影響する部分だけが再ビルドされます。
04
ステータスとトレンドを1か所で
ビルドインサイトがステータス、失敗、所要時間、トレンドを表示するので、プロデューサーはエンジニアに尋ねなくてもビルドの状況を把握できます。
05
エラーのすぐ横に修正案
失敗したビルドは、ステップとコミットを特定し、確認すべきファイルと行を添えて修正案を提示します。
06
チームのいる場所に結果を
ビルドの結果は、SlackまたはMicrosoft Teamsにリアルタイムで投稿されます。
何が変わったか
計測し、そして手放した。ビルドの保守は今やSpeedrunCIの仕事となり、シニアエンジニアの時間はゲーム開発に戻りました。
マネージドランナー保守時間を計測