UnityのアプリビルドをGitHub Actionsに移行した話【CAGC2024】

弊社開発のゲーム開発プロジェクトで利用しているアプリビルドのCIツールの移行についてご紹介します。
弊社ではCIツールとして今までJenkinsを採用してきましたが「ジョブの設定の再利用性とレビューフローの不確立における属人化」と「プラグイン依存における保守性の低下」からGitHub Actionsへの移行を推進しています。
今回はその一環として実施したUnityのアプリビルドをJenkinsからGitHub Actionsへ移行した時の対応例や移行中に発生した問題の解決策などを解説します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=R7qcJi2U

Copyright © CyberAgent, Inc.

Transcript

1. Unityのアプリビルドを GitHub Actionsに移行した話 1 Unityエンジニア 山本 優威 Yamamoto Yui
2. アジェンダ 2 • GitHub Actionsとは • アプリビルドをGitHub Actionsに移行した経緯 • GitHub Actions移行のプロセス • GitHub Actions移行中に起きた問題と対応 • Slack Appを使用したワークフローのトリガー • 今後の展望 • まとめ
3. GitHub Actionsとは 3
4. GitHub Actionsとは 4 「ビルド」「テスト」「デプロイ」のパイプラインを自動化 できる継続的インテグレーションと継続的デリバリー (CI/CD) の プラットフォーム YAMLで記述 特徴 イベントトリガーが豊富 定期実行が可能 公式・非公式含めGitHub上のActionsを使用可能
5. QualiArtsでのGitHub Actions活用事例 5 • 定期的なコードのクリーンアップ • プルリクエストの自動テスト • プルリクエストにラベルの付与 • アプリバージョン毎のブランチの自動マージ
6. アプリビルドをGitHub Actionsに移行した経緯 6
7. 長期間Jenkinsを使用して社内で発生した問題 7 属人化 保守性 の低下
8. 属人化 8 Jobの設定や変更はGUIを通じて簡単に行うことができる Jenkinsの特徴 コードベースでの管理や履歴の追跡の困難化 設定変更のレビューフローの不確立 特徴における問題 デフォルトだとJobの変更履歴はない
9. 保守性の低下 9 多数のプラグインを使用することが可能 Jenkinsの特徴 セキュリティの観点から継続的なアップデートが必要 プラグイン間のバージョン依存によるアップデートの困難化 特徴における問題
10. 問題点を解消できる可能性 10 コードベースでの管理や履歴の追跡 の困難化 属人化 保守性 の低下 プラグイン間のバージョン依存に よるアップデートの困難化 プラグインの代わりにActionを使用 Actionは独立したスクリプトであ り、他のActionに依存することは少 ない 設定変更のレビューフローの不確立 GitHub Actionsのワークフローは YAMLで記載 コードはGitHub上で管理し、 Pull Requestでレビューが可能
11. GitHub Actions移行のプロセス 11
12. 移行前のJenkinsのアプリビルド構成 12 iOS/Androidの各環境ジョブからビルドジョブをトリガーしている ➡ GitHub Actionsでも同様の構成にして手動・定期実行できること 　 を目標にする iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ
13. iOS/Androidビルドジョブのワークフロー作成 13 iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ
14. iOS/Androidビルドワークフローのビルドフロー 14 JenkinsのYAML自体はGitHub Actionsでそのまま使用することが できる為、ビルドフローも大きく変わらない ・Slackにビルド開始の通知 ・inputs入力情報からビルド前準備（環境設定 / サーバー向き先 / 証明書） ・リポジトリのチェックアウト ・Unityビルド ・iOSの場合はXCodeビルド ・App Centerへのアップロード ・Slackにビルド結果の通知 １ ２ ３ ４
15. iOS/Androidビルドジョブのワークフロー作成 15 入力パラメータはinputsに追加 処理はstepsに追加 DevelopやReleaseなど環境によって環境変数を 変更したい為、jobのenvironmentをinputsで 変更できるようにする ① ②
16. iOS/Androidの各環境ワークフローのEnvironment設定 16 登録したsecrets/variablesをstep内で参照することが可能 １ 特徴 同名のsecrets/variablesを作成することで jobのenvironmentを変更するだけで中身の切り替えが可能 2
17. iOS/Androidの各環境ジョブのワークフロー作成 17 iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ
18. iOS/Androidの各環境ジョブのワークフロー作成 18 scheduleによる定期実行の設定 ① 各環境で変更するinputsを設定 ② ③ iOS/Androidビルドのワークフローを 呼び出す ※workflow_callを使用
19. GitHub Actions移行の起きた問題と対応 19
20. ワークフローのInputs上限について 20 ワークフローのInputsに設定できる入力プロパティの最大数は10 問題 Jenkinsでは入力プロパティを10以上設定が可能だったが、 その全てを入力プロパティとして移行することはできない XCode、.NETなどのバージョン系はEnvironment variablesで指定 １ 対応 入力プロパティの1つをJson形式にして受け取る 2
21. Json形式でプロパティを設定・展開 21 workflow_dispatchのinputsにstring型で受け取れるプロパティを用意 １ 設定・展開の流れ step内でjsonを展開し、EnvironmentやOutputに設定 2
22. 今回の例では以下の入力を想定 {"property1":"hoge","property2":"1","property3":"false"} Json形式でプロパティを設定 22 workflow_dispatchのinputsにstring型で受け取れるプロパティを用意 １
23. Json形式でプロパティを展開 23 step内でjsonを展開し、EnvironmentやOutputに設定 ２ ① ② $(echo ${jsonProperties} | jq -r .jsonのkey名) でkeyに対する値を取得 Environment・Outputに設定
24. Json形式の入力プロパティによる問題 24 Json Propeties json形式の入力にしたことにより、keyと値の追加や変更が困難化 問題 Slack Appからjsonのkeyに対する値を入力できるようにGUI対応 １ 対応 dispatchesイベントをトリガーしワークフローを起動 2
25. Slack Appを使用したワークフローのトリガー 25
26. ※ Slack Appについてはコード解説はしません Slack Appを使用したワークフローのトリガーの導入経緯 26 JSON形式のInputsに切り替えたことによるプロパティ入力の対応 エンジニア以外の職種に向けたアプリビルド方法の作成 JenkinsのようなGUIのパラメータ入力の再現 １ ２ ３
27. Slack Appを使用したワークフローのトリガーのGUI 27 作成したSlack Appのホームからモーダルを開き、プロパティを入力可能 Slackのユーザーグループにより表示内容の変更や表示自体がされない実装
28. 今後の展望 28
29. 今後の展望 29 actions/setup-dotnetを使用し、C#スクリプトで処理を動作 ➡ Unityエンジニアなら誰でもメンテナンスができる状態になり 　 属人化を解消する一手を更に打つことに期待 アセットバンドルビルドやバッチ処理なども Jenkinsから移行することで、GitHubのみで完結が可能 １ ２
30. まとめ 30
31. まとめ 31 コードベースでの管理や履歴の追跡 の困難化 属人化 保守性 の低下 プラグイン間のバージョン依存に よるアップデートの困難化 プラグインの代わりにActionを使用 Actionは独立したスクリプトであ り、他のActionに依存することは少 ない 設定変更のレビューフローの不確立 コードはGithubで管理 YAMLからC#コード化可能 GitHub Actionsのワークフローは Pull Requestでレビューが可能