Unity開発の現場でJenkinsがしていることの紹介
はじめに
株式会社QualiArtsでUnityエンジニアをしている住田です。Unityのプロジェクトにてクライアントリードエンジニアをしており、並行して「CA.unity」や「技術書典」といった会社を跨いだ横軸活動の牽引などもしております。 本記事はQualiArts Advent Calendar 2022の1日目の記事です。 今年もQualiArtsのエンジニアがUnity、Golang、組織などのさまざまな記事を毎日投稿しますので、ぜひチェックしてみてください。
さて、Unityを開発している現場で聞き馴染みの多いCIツールといえばJenkinsが有名です。 実際にUnityとJenkinsを使って仕事をしている方はなんとなくアプリのビルドなど運用するタスクが思い浮かぶかと思いますが、そうでない方はあまり馴染みがないのではないでしょうか。 そこで、本記事ではJenkinsについて、QualiArtsのUnityのプロジェクトではどのようなジョブを運用しているかその事例を紹介します。
アプリのビルド
まずアプリの開発を行うということで、もちろん必須になるのがアプリのバイナリを生成するビルドジョブです。モバイルプラットフォーム向けのゲームを開発しているため、iOSとAndroidの両方のビルドを用意しています。
ビルドするアプリにも種類があり、開発用のアプリや提出用のアプリ、特殊な検証を行うためのアプリなどが存在します。開発用のアプリは差分をもとに定常的にビルドを行い、開発チーム全体が最新のアプリを確認できるようにします。それぞれビルドが完了すると結果をSlackに通知します。さまざまな用途のアプリに合わせてジョブを用意しますが、大元の処理のジョブは共通になります。
また、Unityのビルドの前処理、後処理として実装するものについて、各プロジェクトが汎用的に扱えるようUnityのPackageとして開発しています。たとえばiOSビルドにおけるplistやentitlementsの調整などの共通部分が一例で、それをカスタム可能な形で提供しています。
アプリのビルドの一連の流れはどのプロジェクトでも必要になるもので、こうした基盤化によって効率的なフロー構築を目指しています。
アセットバンドルのビルド
アプリのビルドと同様に欠かせないのがアセットバンドルのビルドです。アプリ内には組み込まない外部アセットをアセットバンドルとして各プラットフォーム用にビルドします。
QualiArtsは元々アセットのバージョン管理にSVN（Subversion）を活用していましたが、最近ではPlastic SCMを利用するようになりました。Plastic SCMの活用について気になる方はこちらを参考にしてください。
PlasticSCMでUnityアセットをバージョン管理する
アセットバンドルのビルドジョブの流れとしてはPlastic SCMのワークスペースを更新し、アセットをシンボリックリンクを通じUnityのプロジェクト側に同期してビルドを行う流れです。ここでのUnityプロジェクトについては、実際のアプリのプロジェクトとは別のリポジトリとして作成を行なっています。
ビルドしたアセットバンドルはOctoと呼ばれる社内の管理基盤を用いて管理します。Unityのアセットバンドルのビルドを行い、社内のOctoのサーバーにアップロードするまでがジョブの一連の流れとなります。
Octoについて詳しく知りたい方はこちらを参考にしてください。
複雑化するAssetBundleの配信からロードまでを基盤化した話【CEDEC 2017】
プルリクエストの自動生成
QualiArtsではGitHubならびにgitを利用してコード管理を行なっていますが、開発を進めていく上で単純作業的な変更を必要とする時があります。 たとえばコード整形だったり、サーバー側のデータ構造変更の追従などです。このような基本的にルーチン化された変更を行う際にはJenkinsによって自動でプルリクエストを生成するようにしています。 毎日変更が必要なものは対応する差分があった時や毎日の定まった時間などに自動で実行されるようにし、任意のタイミングで必要になる場合は適宜実行を行います。
ひとつひとつの作業は単調で、それをこなしてプルリクエストを出すだけではあります。ただし、これも積み重なれば大きな工数につながるので、こうした技術による作業効率化はQualiArtsでは積極的に検討および実行するようにしています。
プルリクエストに対するテスト
前項にもあるようにQualiArtsではGitHubでコード管理し、プルリクエストを通してマージを行なっています。 その際にプロジェクト的 にマージして都合が悪くならないかをチェックするためにさまざまなテスト処理を行なっています。コンパイルエラーの検知やPrefabのmissing検知など、コードの品質を担保するための取り組みです。
Jenkinsでこれらを実行するにあたって、Pull Request Builderというプラグインを用いてGitHubのプルリクエストにフックして実行し、それが通るまでマージできないような仕組みにしています。
テストの結果についてはそれぞれ完了後にGitHubのコメントとして通知します。失敗した際にはGitHubのコメントとして失敗した要因が記載されます。たとえばコンパイルチェックの場合はコンパイルエラーの箇所を、Prefabのmissing検知であれば該当のPrefabのプロパティなどが記載される内容です。
このような形をとることで、どのテストでどのような原因で怒られているか通知から認識できるようになっています。
具体的なテストの内容について知りたい方は、弊社のエンジニアが以前のアドベントカレンダーにて執筆しているこちらの記事を参考にしてください。
ちなみに最近まではJenkinsによってこのテスト処理は運用されていたのですが、現在はGitHub Actionsでの活用も行っており、そちらは後述します。
ビルドマシンのUnityのインストール
ビルドマシンにUnityをインストールする処理もJenkins上のジョブとして用意しています。
頻繁にUnityのアップデートを行うわけではないので、直接ビルドマシンに接続して操作し、手動でインストールしてもさほどコストは変わらないかもしれません。しかし、ビルドマシンに直接アクセスする権限は限られたメンバーのみに付与されていることが多く、そういったメンバーに依存せずともUnityのアップデートや検証用にお試しでインストールなどが行いやすいようにジョブとしての運用を行なっています。
GitHub Actionsの検討
最後におまけとして、JenkinsではなくGitHub Actionsの活用検討について紹介します。
ここまで紹介してきたものはすべてJenkins上で運用していますが、保守性などの観点からQualiArtsでも別のCIの手段は議論しており、その中でも検証が進んでいるのがGitHub Actionsになります。 小さいジョブや都合が良さそうなものからGitHub Actionsへの置き換えを検証しています。前述したプルリクエストに対するテストについては、すでに置き換えてプロジェクトで運用できるレベルまで検証が完了しています。
まだまだ検証が必要で少しずつ活用を進めている段階で、完全にJenkinsから乗り換えるというわけではないですが、プルリクエストの生成などJenkinsよりも利便性が高い部分などは積極的に活用していく予定です。
おわりに
JenkinsなどのCIツールを活用してうまく作業を効率化することで、チームの開発速度や生産性を大きく向上させることが可能になります。 QualiArtsではアプリのビルドのような定常的なタスクを運用するだけではなく、コードに対するルーチン化された変更などにも積極的に活用しています。
こういった取り組みの一例が、みなさまの開発の一助になれば幸いです。