[Tokyo DevDays 26'] HordeアップデートとLore入門

HordeとLore 現在のEpicのCIパイプラインで何ができるのか Axel Riffard Software Engineer, Developer Relations Epic Games Japan

自己紹介 フランス出身、日本に住んで14年目 Epic Games Japan に入社して8年 最近良かったゲーム： Red Dead Redemption (iOS版) 最近推している和食：とろニシンのお寿司 最近学んだ日本語：すったもんだ

今日のお話 1 Hordeとは何か そもそもCI/CDとは。Hordeは何をしてくれるのか 2 待つ時間を減らす UBAはもう選ぶものではない。原因究明も自動になる 3 Lore入門 Epicのオープンソースのバージョン管理システム

PART 1 Hordeとは何か

そもそもCI/CDとは ビルド職人だけの話ではない。部署に関係なく、全員に関わる。 誰かが変更を入れる 自動でビルド 自動でテスト これを人が手でやると、どうなるか 忘れる。金曜の夕方は特に忘れる 遅れる。気づくのは、次の人が困ったとき そして、一人にしか分からなくなる だから機械にやらせて、人は作ることに戻る。それがCI/CDの目的だ。 結果を全員に見せる

Hordeとは EpicがFortniteとUnreal Engineのために作り、そのまま公開しているもの 一言で言うと 変更が入るたびに、たくさんのマシンでビルドしてテストして、結果を見せる仕組み してくれることは、大きく3つ ビルドとテストを、社内のマシンに配って走らせる 壊れたとき、どこで壊れたのかを見せる 開発者の手元のコンパイルも、同じマシン群で速くする プログラマーだけの話ではない QAはテスト結果を、アーティストは動くビルドを、プロデューサーは全体の健康状態を見る

大群

Hordeの何がいいのか 他のCIと比べたときに、はっきり違うところ Unrealの言葉を話す 手元のビルドまで速くなる BuildGraphをそのまま動かせる 固定されたパイプ (Opinionated) テレメトリが最初から Perforce、Slack、UGSを狙って作られている エンジンに同梱 壊れたときの扱いがある

1つのジョブが、こう広がる 押すのはボタン1つ。あとは対象プラットフォームごとに、別々のマシンに配られる。 Win64 Linux ダッシュボード コントローラー エージェント エージェント Android エージェント PS5 マシンは自分の能力を申告し、ジョブは必要な条件を書くだけ エージェント

他社の事例：Riot Games 2XKOの移行で公開された数字。うちの数字ではない。 前のビルドシステム Horde ビルド時間 5時間以上 約35分 1日のビルド回数 4〜6回、順番待ち 最低24回、毎時自動で ビルド履歴 直近100ジョブまで 無制限、ステップ単位のテレメトリ 付き 出典：Riot Games「Implementing a Quality Cloud CI System Using Horde」Unreal Fest Gold Coast 2024。

PART 2 待つ時間は、作る時間ではない 5.8の投資が集中したのは2か所。UBAと、原因究明

UBA（Unreal Build Accelerator) はもう「選ぶもの」ではない。 他の分散ビルドがなければ、すでに使っている

「朝いちのビルドに40分かかります」 UBAが既定になった、という話の意味 これまで 最新を取ってきたら、C++の変更が1,200ファイル分あった 自分のPCのCPUだけでコンパイルする その間、PCは重くて何もできない。コーヒーを淹れに行く時間だ 5.8では 社内の空いているマシンに、コンパイルを自動で配る 自分のPCは指示を出すだけなので、軽いまま Hordeがあれば、設定は.iniに数行 誰に効くか C++を触る人全員。エンジンに手を入れているスタジオほど効く 前提 配る先が要る。社内にHordeとエージェントを立てておくこと

リモート実行の確かめかた UbaVisualizer。緑の帯の1本1本が、リモートで走っているコンパイルだ

UBAがいいどん。 そして、無料だどん。

5.8 ! Appleのコンパイルを逃がす 5.8の新機能。MacがiOS / macOSのコンパイルを、LinuxやWindowsに投げられる Apple向けのコンパイラは、LinuxとWindowsで動く版も一緒に配られている 5.8は、その2つを結びつけた 結果、Macは指揮を執るだけでよくなる 重いコンパイルは、空いている他のOSのマシンに出せる iOS対応のためにMacを何十台も買う、という前提が変わる

「誰のせいか、分かりません」 自動RCAが引き受けてくれること これまで ビルドが赤くなる。まず「自分かな」と思う 200件の変更のどれが原因か、人が探す だいたい、いちばん詳しい人が毎回呼ばれる 5.8で入ったもの Issueができた瞬間に、原因究明の依頼が自動で積まれる Redisのキュー。リトライ3回、サーバーが落ちても消えない 結果の型（犯人・信頼度・次点）と、通知の仕組みが決まっている 自分で書くもの 判定エンジン。自社のルールを差し込む それを書いて、はじめて「このコミットが怪しい」が返る

見えるとこうなる Hordeに元から入っている分析画面。エディタの起動時間とロード時間が、ストリームごとに並ぶ 行はストリームとマップの組み合わせ、 右の数字が読み込み時間だ。 緑から赤に変わったところが、遅くなった地点。 「いつから」に指で答えられるようになる。

始めかた 評価するだけなら、用意するものはない Windows Linux / macOS インストーラーを1つ入れるだけ サーバーは動くが、 データベースも同梱されていて、 データベースは自分で用意する サーバーが自分で起動する 同梱の自動起動はWindowsだけの機能 認証なしで、すぐ画面が開く エージェントのサービス化コマンドも エージェントもコマンド1つで サービス登録まで終わる Windows向け

Perforceなしで使える範囲 「うちはSVNなので関係ないですよね」。そうとは限らない Perforceが要らない Perforceが要る Compute Buildプラグイン リモート実行、UBA、エージェント、プール CIそのもの。ジョブ、ストリーム、 Storage / Tools / Symbols プリフライト（shelveを使う） 成果物、ツール配布、シンボル Analytics デバイスマネージャーもこの中 テレメトリ コード自体はPerforceを使わないが、 同じ袋に入っている

Hordeは「Perforce前提」をやめつつある 5.8のソースを見ると、方向がはっきり出ている 5.8で、ストリーム設定に「どのVCSか」という項目が入った 既定値はPerforce。既定値がある、ということは、他もありうる、ということだ コミットの識別子は、もう番号ではない 数バージョン前から文字列だ。チェンジリスト番号への依存を、順に外している ただし、まだ全部ではない プリフライトとサブミットは、今もPerforceのまま

PART 3 入門 Epicのオープンソースのバージョン管理システム

リポジトリで管理する2つの要素 そして、この2つは求めるものが正反対だ コード コンテンツ 全体の5%くらい 全体の95%くらい きれいにマージできる マージできない 小さいファイルが大量にある 1ファイルが数百MBある 全員が全履歴を必要とする 最新版が重要 → Gitが強い領域 → Perforceが強い領域

Loreとは 中央集権型のバージョン管理システム。データは中身のハッシュで管理する。正となるのはサーバ ーだ。stage、commit、ブランチはローカルで完結する。 MIT Rust ライセンス ランタイム不要 試す価値はある。でも本番投入はまだ早い。 Pre1.0 UEFN すでに稼働中

Lore Desktop GUIはある。アーティストが最初に聞いてくるのはここだ。

区切りを中身で決める FastCDC。1つ64KiBくらい、最大256KiB。切る場所は固定位置ではなく、中身のパターンで決める。 固定位置で切ると 元のファイル 1MB挿入後 後ろが全部ずれる→全部新規 中身で切ると 元のファイル 1MB挿入後 変わった1つだけが新規 本当に変わった部分だけが保存される。これがLFSとの一番の違いだ。

自分で計測した 同じ120MiBのファイル、同じ手順、同じマシン。3リビジョン後のディスク使用量。 手順 1回目 登録 2回目 1MB上書き 3回目 1MB挿入 挿入は後ろが全部ずれるので、いちばん厳しい条件 だ。 Loreは120 → 121 → 123 MB Gitはgc --aggressiveで122MBまで戻るが、 手作業での実行が必要で、10.85秒かかった。 Git LFSは戻らない。 差分を取らない設計だからだ。 新人が最初に落とすデータ：Loreのbareクローンは2.3KB / 0.31秒。git cloneは243MB。 Lore 0.8.6 / Git 2.43.0 / Git LFS 3.4.1。

他のツールを使っている方へ つまずくのはほとんど概念ではなく、名前だ。 Perforce SVN Git Lore p4 sync svn update git pull lore sync p4 edit （不要） （不要） lore dirty / status --scan p4 add, reconcile svn add git add lore stage p4 submit svn commit git commit + git push lore commit → lore push チェンジリスト リビジョン番号 コミット リビジョン p4 changes svn log git log lore history ストリーム branchesへのコピー ブランチ ブランチ（軽いポインタ） ワークスペース 作業コピー sparse-checkout ビューフィルタ付きツリー p4 lock svn lock git lfs lock lore lock acquire

今できること、できないこと 日常の操作は一通りそろっている。足りないものも、はっきりしている。 今できる 注意が必要 まだない サーバーが数分で立つ ロックは強制しない UE用のエディタプラグイン stage、commit、push、sync ツリーごとに実体を持つ UEFN版Loreとの相互接続 ブランチ、切り替え、マージ Desktopはバイナリ配布のみ 仮想ファイルシステム 部分クローン、bareクローン サーバー階層は2段まで Webクライアント、レビュー ロック（強制なし） pre-1.0、APIは変わる フック、フォーク 6言語のSDK

CI/CDとの連携 今は連携と呼べるものがない。 今できること まだないもの エージェントにCLIを入れる Horde連携はない bareや部分クローンで必要な分だけ取得 Jenkinsプラグインもない 6言語のSDKで自前の連携を書く pushで発火するフックもまだ リビジョンにメタデータを付けられる Webhookもまだ つまり今はポーリングだ。

今のLoreとの付き合いかた どれも「本番のプロジェクトに入れましょう」ではない あなたの状況 おすすめ Perforceで出荷中 触らない。強制ロックと、P4V級のGUI・エンジン統合がまだない Git LFSがつらい 捨てていいコピーで測ってみよう。本体はそのままで プロトタイプやジャム どうぞ。今いちばん向いている ツールを作っている APIから見てみよう。仕様公開は設計に入れる価値がある

持ち帰っていただきたいこと 1 5.8では、UBAが標準のビルド経路になった そしてUBAはWindows専用ではない。MacのコンパイルをLinuxに逃がせるようになった。 2 Hordeは「Perforce前提のCIツール」をやめつつある 3 Loreは試す段階。本番は1〜2年先 データを入れるのは安全。ロックの強制、仮想ファイルシステム、エディタ統合を待とう。

ご清聴ありがとうございました Merci ! Q&A ?