Tweet
Tweet

Slide 1

Slide 1 text

Unityのアプリビルドを GitHub Actionsに移行した話 1 Unityエンジニア 山本 優威 Yamamoto Yui

Slide 2

Slide 2 text

アジェンダ 2 ● GitHub Actionsとは ● アプリビルドをGitHub Actionsに移行した経緯 ● GitHub Actions移行のプロセス ● GitHub Actions移行中に起きた問題と対応 ● Slack Appを使用したワークフローのトリガー ● 今後の展望 ● まとめ

Slide 3

Slide 3 text

GitHub Actionsとは 3

Slide 4

Slide 4 text

GitHub Actionsとは 4 「ビルド」「テスト」「デプロイ」のパイプラインを自動化 できる継続的インテグレーションと継続的デリバリー (CI/CD) の プラットフォーム YAMLで記述 特徴 イベントトリガーが豊富 定期実行が可能 公式・非公式含めGitHub上のActionsを使用可能

Slide 5

Slide 5 text

QualiArtsでのGitHub Actions活用事例 5 ● 定期的なコードのクリーンアップ ● プルリクエストの自動テスト ● プルリクエストにラベルの付与 ● アプリバージョン毎のブランチの自動マージ

Slide 6

Slide 6 text

アプリビルドをGitHub Actionsに移行した経緯 6

Slide 7

Slide 7 text

長期間Jenkinsを使用して社内で発生した問題 7 属人化 保守性 の低下

Slide 8

Slide 8 text

属人化 8 Jobの設定や変更はGUIを通じて簡単に行うことができる Jenkinsの特徴 コードベースでの管理や履歴の追跡の困難化 設定変更のレビューフローの不確立 特徴における問題 デフォルトだとJobの変更履歴はない

Slide 9

Slide 9 text

保守性の低下 9 多数のプラグインを使用することが可能 Jenkinsの特徴 セキュリティの観点から継続的なアップデートが必要 プラグイン間のバージョン依存によるアップデートの困難化 特徴における問題

Slide 10

Slide 10 text

問題点を解消できる可能性 10 コードベースでの管理や履歴の追跡 の困難化 属人化 保守性 の低下 プラグイン間のバージョン依存に よるアップデートの困難化 プラグインの代わりにActionを使用 Actionは独立したスクリプトであ り、他のActionに依存することは少 ない 設定変更のレビューフローの不確立 GitHub Actionsのワークフローは YAMLで記載 コードはGitHub上で管理し、 Pull Requestでレビューが可能

Slide 11

Slide 11 text

GitHub Actions移行のプロセス 11

Slide 12

Slide 12 text

移行前のJenkinsのアプリビルド構成 12 iOS/Androidの各環境ジョブからビルドジョブをトリガーしている ➡ GitHub Actionsでも同様の構成にして手動・定期実行できること 　 を目標にする iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ

Slide 13

Slide 13 text

iOS/Androidビルドジョブのワークフロー作成 13 iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ

Slide 14

Slide 14 text

iOS/Androidビルドワークフローのビルドフロー 14 JenkinsのYAML自体はGitHub Actionsでそのまま使用することが できる為、ビルドフローも大きく変わらない ・Slackにビルド開始の通知 ・inputs入力情報からビルド前準備（環境設定 / サーバー向き先 / 証明書） ・リポジトリのチェックアウト ・Unityビルド ・iOSの場合はXCodeビルド ・App Centerへのアップロード ・Slackにビルド結果の通知 １ ２ ３ ４

Slide 15

Slide 15 text

iOS/Androidビルドジョブのワークフロー作成 15 入力パラメータはinputsに追加 処理はstepsに追加 DevelopやReleaseなど環境によって環境変数を 変更したい為、jobのenvironmentをinputsで 変更できるようにする ① ②

Slide 16

Slide 16 text

iOS/Androidの各環境ワークフローのEnvironment設定 16 登録したsecrets/variablesをstep内で参照することが可能 １ 特徴 同名のsecrets/variablesを作成することで jobのenvironmentを変更するだけで中身の切り替えが可能 2

Slide 17

Slide 17 text

iOS/Androidの各環境ジョブのワークフロー作成 17 iOS - Customジョブ iOS - Developジョブ iOS - Stagingジョブ iOS - Releaseジョブ Android - Customジョブ Android - Developジョブ Android - Stagingジョブ Android - Releaseジョブ iOSビルドジョブ Androidビルドジョブ

Slide 18

Slide 18 text

iOS/Androidの各環境ジョブのワークフロー作成 18 scheduleによる定期実行の設定 ① 各環境で変更するinputsを設定 ② ③ iOS/Androidビルドのワークフローを 呼び出す ※workflow_callを使用

Slide 19

Slide 19 text

GitHub Actions移行の起きた問題と対応 19

Slide 20

Slide 20 text

ワークフローのInputs上限について 20 ワークフローのInputsに設定できる入力プロパティの最大数は10 問題 Jenkinsでは入力プロパティを10以上設定が可能だったが、 その全てを入力プロパティとして移行することはできない XCode、.NETなどのバージョン系はEnvironment variablesで指定 １ 対応 入力プロパティの1つをJson形式にして受け取る 2

Slide 21

Slide 21 text

Json形式でプロパティを設定・展開 21 workflow_dispatchのinputsにstring型で受け取れるプロパティを用意 １ 設定・展開の流れ step内でjsonを展開し、EnvironmentやOutputに設定 2

Slide 22

Slide 22 text

今回の例では以下の入力を想定 {"property1":"hoge","property2":"1","property3":"false"} Json形式でプロパティを設定 22 workflow_dispatchのinputsにstring型で受け取れるプロパティを用意 １

Slide 23

Slide 23 text

Json形式でプロパティを展開 23 step内でjsonを展開し、EnvironmentやOutputに設定 ２ ① ② $(echo ${jsonProperties} | jq -r .jsonのkey名) でkeyに対する値を取得 Environment・Outputに設定

Slide 24

Slide 24 text

Json形式の入力プロパティによる問題 24 Json Propeties json形式の入力にしたことにより、keyと値の追加や変更が困難化 問題 Slack Appからjsonのkeyに対する値を入力できるようにGUI対応 １ 対応 dispatchesイベントをトリガーしワークフローを起動 2

Slide 25

Slide 25 text

Slack Appを使用したワークフローのトリガー 25

Slide 26

Slide 26 text

※ Slack Appについてはコード解説はしません Slack Appを使用したワークフローのトリガーの導入経緯 26 JSON形式のInputsに切り替えたことによるプロパティ入力の対応 エンジニア以外の職種に向けたアプリビルド方法の作成 JenkinsのようなGUIのパラメータ入力の再現 １ ２ ３

Slide 27

Slide 27 text

Slack Appを使用したワークフローのトリガーのGUI 27 作成したSlack Appのホームからモーダルを開き、プロパティを入力可能 Slackのユーザーグループにより表示内容の変更や表示自体がされない実装

Slide 28

Slide 28 text

今後の展望 28

Slide 29

Slide 29 text

今後の展望 29 actions/setup-dotnetを使用し、C#スクリプトで処理を動作 ➡ Unityエンジニアなら誰でもメンテナンスができる状態になり 　 属人化を解消する一手を更に打つことに期待 アセットバンドルビルドやバッチ処理なども Jenkinsから移行することで、GitHubのみで完結が可能 １ ２

Slide 30

Slide 30 text

まとめ 30

Slide 31

Slide 31 text

まとめ 31 コードベースでの管理や履歴の追跡 の困難化 属人化 保守性 の低下 プラグイン間のバージョン依存に よるアップデートの困難化 プラグインの代わりにActionを使用 Actionは独立したスクリプトであ り、他のActionに依存することは少 ない 設定変更のレビューフローの不確立 コードはGithubで管理 YAMLからC#コード化可能 GitHub Actionsのワークフローは Pull Requestでレビューが可能