「Jenkinsユーザー向けの乗り換えガイド： UE5のHorde へようこそ！」

「Jenkinsユーザー向けの乗り換えガイド： UE5のHorde へようこそ！」 Axel Riffard Epic Games Japan Software Engineer, Software Relations

日本在住13年目、フランス出身 EGJに入社して7年 最近の推し和食：にんにくバター鍋 GOTYはとにかくExpedition33 X : @AxRiff

Jenkinsの遺産 15年以上にわたり、Jenkinsは業界全体でデフォルトのCI/CDプラットフォーム オープンソース、 プラグイン天国のエコシステム、 柔軟性で、 小規模スタジオから AAA規模まで その強みは適応性にあり、 ほぼすべてのエンジン、 ToolChain、 バージョン管理システムを統合可能

なぜJenkinsが人気なのか Jenkinsが標準となった主な理由: 何千ものプラグインがあらゆるワークフローに対応 エンジンに依存しない。Unity、Unreal、自社エンジンなどに対応する 10年以上にわたる本番環境での使用と広範なコミュニティ 安定したパイプラインモデル：スクリプトビルド、手動トリガー、スクリプトによる自動化をサ ポートする スケーラブル:マスター/エージェント構成を通じて大規模なチームを処理 これらの強みが、Jenkinsがさまざまな開発環境で信頼され続けている理由を説明する

だから言いたいのは... Jenkinsの長い成功の歴史がすごい！ 信頼性があってゲーム業界に愛されているソフトウェア EpicがHordeへの移行はUnrealの成長から生まれた必要性であり、 すでに市場に出ているもののあらゆる問題点を検出しようとしたものだった

Jenkinsが制限されるとき JenkinsはUE5特有の技術的負荷に耐え始める: 数千のシェーダーと大規模なレベルデータのアセットベース マルチプラットフォーム要件: Windows、macOS、Mobile、Console向けの同時構築 複雑なBuildGraph依存関係がJenkinsのjob chainに十分に表れていない State Agentや手動メンテナンスは柔軟性を制限する TB規模のプロジェクトが普通の世界になった それくらいのデポに成長するにつれて、伝統的なJenkinsはボトルネックを生み出す

一般的なJenkins + UE5パイプライン - .batベースのビルドステップ - インストールされた依存関係や状態を維持する必要があるエージェント - Unrealのバージョンやプラグインの手動アップデート - テスト、デバイス、資産のビルド状況の確認が見にくい - 機能的ではあるが、Unrealスケールでは脆弱で手間がかかる

現在の課題 Jenkinsを使うUnrealチームでよくある課題: 暇なエージェント デバッグが難しい →一人のJenkins達人がいて、他の人が真っ暗の中 パイプライン間の再利用は制限されている テレメトリやテストが足りていない 基本的にパイプラインは静的で手動で、スケールが難しい →プロジェクトが増えたらパイプラインも増やす

チームへの影響 開発よりもビルドシステムのメンテナンスに時間を利用 QAの場合、CIの結果を待つことで検査サイクルが遅れる プロデューサーの場合、正確なビルドの健康状態やスケジュールの確認しづらい スタジオ全体的に、反復の遅延、最適化の機会の逃し CIは開発を加速させるべき。開発の邪魔になった場合は改善するべき。

そこで Horde

EpicではCI/CDの開発を考え始めたとき、すでにあるものの再発明を望まず、 自分たちのニーズに合わせてエコシステムに深く統合することゴールにした EpicはUnrealの開発には、「サポート」があるだけでなく、Unrealを中心に構築 されたインフラが必要であることを理解した これにより、大規模なUnrealパイプライン、自動化、テスト向けに設計されたシ ステムHordeが誕生した

Hordeの紹介 この数年間HordeはEpic社内のCI/CDで、Fortnite、Rocket League、そしてEngine本 体のために開発と使用されている Jenkinsの後継者ではなく、統合されたスタジオインフラ ビルドやテストからデバイスオーケストレーション、テレメトリまで、あらゆる管理を 行っている

比較 Jenkins Horde スクリプトパイプライン JSON 手動環境管理 不変環境 限定的Perforce,GIT, SVN積分 ネイティブPerforce統合

大群

HordeはCI/CD以上の存在 リモートデバイス管理 ヘルスダッシュボード 分散コンパイル(Unreal Build Accelerator) テスト管理 社内向けのプチWikiと車内向けのコミュニケーションツール

Hordeのコアデザイン原則 Perforce中心: ChangeListワークフロー向け スクリプトの代わりにJSONベース 不変環境: 再現可能でバージョン制御可能なビルドコンテキスト 分散スケジューリング: エージェント間のジョブ分配を最適化 BuildGraphやUEの自動化、コードやシェーダー分散コンパイルなどのネイティブサポート

パーフォース中心モデル ストリームとチェンジリストの自動トラッキング 決定論的ビルドのためのBuildGraphターゲットとの統合 チェックイン前に事前フライトの提出を強制 Perforceユーザーには強力な機能だが、Git/SVNプロジェクトには向いてない

統合Epic環境 HordeはBeta的なものではなく、Epicは長年にわたり社内で利用 Fortnite、Rocket League、Unreal EngineのビルドはすべてHordeを経由する これにより、成熟度、性能、そして実際の生産で実証されたスケーラビリティが保証

サーバー立ち上げ方 ローカル: 完全な管理と機密保持 ハイブリッド: ローカルビルドエージェントとクラウド容量の混合 クラウド： 完全にリモート（AWS)設備 Docker: テストやスケーリングに快適 Jenkins環境と比較するためのローカルセットアップにしよう

Global.json *.Project.json *.Streams.json *.Project.json *.Streams.json

Perforceサーバーアドレスと情報 UGSパラメータ ダッシュボードの表示情報 Hordeプラグインの設定 ストレージ設定 アクセス制御リスト(ACL) Global.json *.Project.json *.Streams.json *.Project.json *.Streams.json

Perforceの配信で使うべきもの 全体的にプロジェクト情報 Global.json *.Project.json *.Streams.json *.Project.json *.Streams.json

Global.json CICDのカテゴリ タスクとパラメタの保存 *.Project.json *.Streams.json *.Project.json *.Streams.json

globals.Json

HordeはBuildGraphを使用 すでに持って、何年も動作しているBuildGraphは、デフォルトでサポートされている また、Unrealのゲームに必要なすべてのTaskは、すでにローカルエンジンリポジトリに存在している 他のプロジェクトからスクリプトを書いたり、移植したりする必要はない 例を見てみよう

包装と試験 パッケージングターゲット(Windows、Android、iOSなど)を定義し、 最初から最後まで自動化 各ビルド後にテスト(機能、パフォーマンスなど)が自動的にトリガーされ、 結果はダッシュボードで確認できる

もっとUnreal向けの例をみてみよう

Preflight機能 普通のフローだと、作ったものをサブミットしてビルド壊したかどうかドキドキしながら待つ。 そのドキドキを無くさせえよう Perforce中心だからこそ簡単にできる ChangelistをPreflightして、全プラットフォームに問題を起こしていないことを確認した後に サブミットされる。

Preflight Submit Flow Perforceと統合されたプリフライトシステムにより、 提出前にビルドやテストがチェックされる Epicではこの方針が長年義務付けられており、 後退が主流に入るのを防ぎ この４年間、 Epic内でルールになっていて、 優秀であったため、 こういったフローがないチームで働けない 是非どんなスタジオでも強制しよう

P4V内の実装もござる

Preflight Submit flow HordeはP4Vプラグインを提供しており、開発者はエディターやP4Vクライアントから直接 プリフライトビルドをトリガー CAPTURE PLUGIN

Unrealとの仲良さそれだけではない

スタンドアロンビルドとUGS統合 Unreal Game Sync(UGS)は、Epic GamesがUnreal Engineで使用するために開発した同期ツール エンジニアではない人でもコンパイル済みバイナリと簡単に同期できるソフト Hordeとの統合により、ChangeListバッジ、ビジュアルビルドステート、ストリームの情報確認 これにより、アーティストやQAチームはエンジニアリングから独立して運営できるようになる

スタンドアロンビルドとUGS統合 Perforceのバージョン管理と統合できるグラフィカルなフロントエンドを提供し、 オプションでビルドをトリガー(例えばVisual Studioなど) ゲームプロジェクトに携わるチームが、 プロジェクトが進化する中でコードとコンテンツを同期させるのを支援するために設計されている

スタンドアロンビルドとUGS統合 コードとコンテンツの同期により、チームのワークスペース全体は一つになる 特定のChangeListに早くアクセスし、エディタのバージョンを合わせて再構築し、ビルド に問題あるかどうかでマークしてチームに共有 エディターを同期できる機能により、ローカルコンパイルへの依存度が減る カスタムビルドのステップやユーティリティをワークフローに統合し、プロジェクトのニー ズに合わせてUGSを適応させることができる

テストの自動化

自動テスト統合 テスト定義: Unreal EditorまたはBuildGraph内で宣言 実行: Hordeとガントレットを遠隔で進める 結果の可視性: Hordeダッシュボードに直接表示される

Night Test Cycle ユースケースとして、 すでにあるテスト利用するだけで、 寝ている間に段末にテスト実行のフローが簡単にできて、 次のHordeのDashboardで表示

分散ビルド （ソース＋シェーダー）

UBA統合 HordeはUnreal Build Accelerator(UBA)を統合し、コードとシェーダーの両方を分散コンパイル UBAはアンリアル利用者が無料で利用可能

テレメトリー スタジオ全体のテレメトリー ロード時間、 ビルド時間、 クラッシュ頻度など集め、 リードがパフォーマンスのボトルネックを特定し、 パイプライン効率を向上させるのを支援

ツール配布機能 Hordeには、承認済みのツール、プラグイン、バイナリを配布するための中央リポジトリが含まれる これにより一貫性が確保され、バージョンの競合を避け、オンボーディングが加速される スタジオ内のホームページとして利用がいいかも？

まとめ

伝わった？ 結局BuildGraph、UnrealGameSync、AutomationTest、 BuildAccelerator… Horde以外の話が多くなる 理由は二つある： - Hordeは簡単に設定できて深さとクセのないツール - Unrealのエコシステム長身で開発され、UE機能と相性がいい

ただ…

Jenkinsがいいとき マルチエンジンパイプ GitやSVNに依存がある カスタムオートメーションとインフラへの投資はかなりある

Hordeがいいとき Unrealプロジェクトが多い Perforce利用 統合テスト、テレメトリーなもっとしっかりしたい 分散ビルド系のソフトを利用していてコストのことを考えたい EpicがHordeにコミットしている。 UEの利用者なら、乗り換えの時期が早めに検討した方がいい

実装検討勉強用 Hordeの実装： Jack CondonのUnreal Fest Baliのトーク Ben MarshのUnreal Fest USトーク Test/Gauntlet : https://qiita.com/donbutsu17/items/cd17d500a9fed143e061 https://github.com/S1Lazza/GauntletAutomationDemo UBA : https://dev.epicgames.com/community/learning/knowledge-base/jB32/unrealengine-practical-debugging-tips-for-unreal-build-accelerator

• https://qiita.com/donbutsu17/items/cd17d500a9fed143e061
• https://github.com/S1Lazza/GauntletAutomationDemo
• https://dev.epicgames.com/community/learning/knowledge-base/jB32/unreal-

MERCI ! Q&A ?