GitHub Actions x Unity プロジェクトの裏側

GitHub Actions x Unity プロジェクト の裏側 2024/08/02 Unity CI/CD 完全に理解した 勉強会 © DeNA Co., Ltd. 1

登壇者プロフィール 白柳 隆澄 株式会社ディー・エヌ・エー ゲームサービス事業本部開発運営統括部第一技術部 テクノロジー推進第三グループ グループリーダー 2007年からゲーム業界でエンジニア 2017年DeNA入社 2019年頃からSREを自称 「ゲーム開発者のための SRE」として開発 をいかに楽にしていくか 毎日考えています © DeNA Co., Ltd. 2

はじめに ● SRE の業務の１つとして CI/CD の環境構築・運用・改善を行っています ● 複数の Unity プロジェクトに GitHub Actions の Self-hosted runner を提供 © DeNA Co., Ltd. 3

目次 1 Jenkins から GitHub Actions に変えたよ 2 Jenkins と GitHub Actions で〇〇が違うよ 3 常駐型 Self-hosted runner を使ってるよ 4 Unity プロジェクトのために〇〇を工夫してるよ 5 まとめだよ © DeNA Co., Ltd. 4

Jenkins から GitHub Actions に変えたよ © DeNA Co., Ltd. 5

Jenkins から GitHub Actions に変えたよ 1 ● TechCon 2023 時点では Jenkins とのハイブリッドとGitHub Actions のみのプ ロジェクトがあった https://techcon2023.dena.dev/session/session4/ ● 当初はアプリビルドは Jenkins のまま、それ以外のPR のチェックや開発作業 の自動化などを GitHub Actions で行う想定だった ● ハイブリッド運用してたプロジェクトでも Jenkins を廃止 GitHub Actions に移行した ● 現在 Unity プロジェクトはすべて GitHub Actions になった © DeNA Co., Ltd. 6

• https://techcon2023.dena.dev/session/session4/

なぜハイブリッドやめたのか？ 1 ● ２つの環境を運用するのはやはり大変 ● 開発中からリリースが視野に入った段階で ビルドと連携するワークフローの需要が増えた © DeNA Co., Ltd. ○ ビルド成果物を使ってなにかするジョブの需要 ○ Jenkins にジョブを追加するよりは GitHub Actions に追加したい ○ GitHub Actions と Jenkins 間で成果物を受け渡したりトリガーしたりなどは手間 ○ コスト掛けてでも移行することにした 7

ハイブリッドやめた結果 2 ● 管理者 ○ ● 開発者がやりたいこと実現するための管理維持コスト削減 ■ CI/CDできる場を作るまでを担当 ■ 依存ツール類の管理が不要になった（一部を除く） 開発者 ○ © DeNA Co., Ltd. 両者両得 やりたいことを管理者の手を借りることなく実現できる ■ YAML書けばすぐにワークフローを実行できる ■ 必要なツールはジョブでセットアップ 8

JenkinsとGitHub Actionsで〇〇が違うよ © DeNA Co., Ltd. 9

2 JenkinsとGitHub Actionsで〇〇が違うよ Jenkins ユーザーが運用 内容 コントローラー GitHub Actions GitHub / GitHub Enterprise 2,000 弱 プラグイン/アクション 10,000以上 GUI / JCasC plugin コントローラー設定 不要 GUI / Jenkinsfile / JCasC ワークフロー（ジョブ）設定 YAML GUI / Jenkinsfile / Groovy ワークフロー（ジョブ）定義 YAML GUI / JCasC © DeNA Co., Ltd. シークレット変数 GUI / (Terraform) 10

2 JenkinsとGitHub Actionsで〇〇が違うよ Jenkins ユーザーが運用 可能 ジョブごと プリインストール 内容 GitHub Actions エージェント/ランナー GitHub hosted / Self-hosted 同一マシンでの同時実行 1ジョブのみ※ ワークスペース リポジトリごと 実行環境セットアップ ジョブでセットアップ GitHub Pull Request Builder Plugin PRでトリガー 標準 GitHub Plugin Pushでトリガー 標準 その他イベントトリガー 標準 プラグインがあれば・・・ © DeNA Co., Ltd. ※1ランナープロセスにつき１つまで 11

常駐型Self-hosted runnerを使ってるよ © DeNA Co., Ltd. 12

全社ランナーとプロジェクトランナー 3 ● 全社ランナー ○ DeNA の GitHub Enterprise Server 環境下で利用できるランナー ○ 社内の管理者から提供されておりプロジェクトは自由に使用できる ■ ○ ● プロジェクトとしてはランナー管理コストが０ GitHub hosted runner のような環境 プロジェクトランナー © DeNA Co., Ltd. ○ ゲーム開発プロジェクトのためのプロジェクト専用ランナー ○ Unity をプリインストール 13

3 全社ランナーとプロジェクトランナーの違い 全社ランナー Self-hosted runner GitHub hosted runner 相当 内容 ランナー ランナーバージョン プロジェクトランナー Self-hosted runner GitHub hosted runner 相当 コンテナ 提供方式 マシン常駐 Linux OS Linux/macOS なし Unity あり © DeNA Co., Ltd. 14

常駐型ランナーを使用する理由 3 ● ● ● Unity をジョブでセットアップするのは大変 ○ Jenkins 時代と同様にプリインストール ○ 全社ランナーでも Unity をプリインストールは技術的には可能 全社ランナーに macOS がない ○ Linux Unity を部分的に使ってるプロジェクトもある ○ Apple Silicon が速いので大規模開発のビルドマシンは macOS がメイン キャッシュサイズの問題 ○ Library ディレクトリをキャッシュしたいが GitHub Actions のキャッシュではサ イズが大きすぎて無理だった © DeNA Co., Ltd. 15

常駐型ランナーで気をつけなければいけないこと 3 ● ● グローバルな設定変更やツールのインストールなどをしてはいけない ○ 次のジョブに影響してしまう ○ git config --global とか、brew install とか シークレットなファイルをワークスペースに残さない © DeNA Co., Ltd. ○ 次のジョブで見ることができてしまう ○ Post 処理などで必ず消す、もしくは環境変数を使う 16

常駐型ランナーで気をつけなければいけないこと 3 ● 前の状態が残っていることを想定できてないアクションがある ○ ● actions/checkout で sparse-checkout するとそれしかできなくなる、とか 常駐型ならではワークフローの書き方が必要になる ○ © DeNA Co., Ltd. com の方で GitHub Actions に慣れているとハマってしまいがち 17

Unity プロジェクトのために 〇〇を工夫してるよ © DeNA Co., Ltd. 18

Unity プロジェクト向けの工夫 4 ● ライセンス管理 ● キャッシュ・ワークスペースの分離 ● 長過ぎる Unity のビルドログから問題を検出する ● １マシンで複数ランナー運用 © DeNA Co., Ltd. 19

ライセンス管理 4 ● Unity Build Server License ○ ● https://unity.com/ja/products/unity-build-server フローティングライセンス ○ 現状、最大同時実行数=マシン台数分を使用している ● Pro ライセンスより安い ● GUI 使えないビルド用のライセンス © DeNA Co., Ltd. 20

• https://unity.com/ja/products/unity-build-server

キャッシュ・ワークスペースの分離 4 ● 常駐型ランナーのため、前のジョブの状態が残っている ○ Library ディレクトリが残っているので actions/checkout で clean: false にすれば 前回ビルド時のキャッシュをそのまま利用できる ○ actions/checkout 後に Library 以外をクリーンする e.g. git clean -xffd --exclude Library © DeNA Co., Ltd. 21

キャッシュ・ワークスペースの分離 4 ● １リポジトリ１ワークスペースのため 他のジョブで clean されてしまうことがある ○ https://github.com/DeNA/setup-job-workspace-action を使ってジョブごとにワークスペースを作成 ○ ジョブごとのワークスペースはディスク容量を圧迫するので 定期的に未使用ディレクトリを削除する cron をマシンに設定 © DeNA Co., Ltd. 22

• https://github.com/DeNA/setup-job-workspace-action

長過ぎる Unity のビルドログから問題を検出する

4

●

ログ中から警告や問題を検出するアクションを作成し各プロジェクトで利用
○

reviewdog の errorformat を用意して検出
guid-conflict:
name: "${INPUTS_NAME_PREFIX} - guid-conflict"
cmd: "${LOG_STDOUT_COMMAND} ${INPUTS_LOG_PATH}"
errorformat:
- "%+AGUID %s for asset '${INPUTS_FILE_RELATIVE_PATH}%f' conflicts with:"
- "%C\ \ %m"
- "%Z%m"

●

Problem Matcher を使うのもアリ
○

© DeNA Co., Ltd.

※ envsubst して環境変数展開した.reviewdog.yml を使用

setup-dotnet 使うとC#のエラー・警告はこれによりアノテーションされる
23

１マシンで複数ランナー運用 4 ● GitHub Actions は１ランナーで同時に１つのジョブしか実行できない ● Unity を使うジョブをなるべくキュー待ちさせたくないので Unity 専用ランナーを作成 © DeNA Co., Ltd. ○ Unity 使うジョブが走ってないときはアイドルする ○ ハイスペックマシン常駐させてるのにもったいない ○ Unity 以外のジョブも入るようにすると Unity ジョブが待たされるかもしれない 24

１マシンで複数ランナー運用 4 ● １マシンで Unity 専用ランナーと汎用ランナーの ２プロセスを実行することにした ● （やってみたらできたので）この構成で２年くらい運用してる ● 常駐型で気をつける点があるのに 複数ランナーでさらに気をつける点が増えた © DeNA Co., Ltd. 25

１マシン複数ランナーで気をつけなければいけないこと 4 ● 別プロセスのランナーに影響を与えてはいけない ○ グローバルな設定を変えてはいけない ○ 固定パス、キャッシュパスをランナーごとに設定する必要がある ■ 一部の setup はランナーディレクトリ以下ではなくグローバルなパスに キャッシュするものがある ○ プロセスごとに環境変数でパスを設定 ■ DOTNET_INSTALL_DIR など ■ GIT_CONFIG_GLOBAL は actions/checkout との相性悪くて断念 actions/checkout は git config –-global を変更するが対策されている © DeNA Co., Ltd. 26

まとめ © DeNA Co., Ltd. 27

まとめ ● ● ジョブが必要なものはジョブが準備するとWin-Win ○ GitHub Actions になって自然と実現 ○ ビルドマシンも増やしやすい ○ ワークフロー開発もしやすい Unity プロジェクトのために専用の GitHub Actions self-hosted runner を運用 © DeNA Co., Ltd. ○ ビルドマシンの管理業務は大幅に減ったが大規模なプロジェクトでは必要 ○ 常駐型・複数ランナープロセスの運用例を紹介しました 28

© DeNA Co., Ltd. 29