Mirrativ Tech Blog

株式会社ミラティブの開発者(バックエンド,iOS,Android,Unity,機械学習,インフラ, etc.)によるブログです

ミラティブのUnityアセット運用とそれを支えるCI/CD

こんにちは、ミラティブUnityエンジニアの菅谷です。

ミラティブでは週に一回以上のペースでエモモのイベントを行っており、1つのイベントごとに約40個の衣装やエモモアイテムを追加しています。 エモモアイテムの多くはUnityを活用して作られており、アセットバンドルとして追加・更新されます。 今回はハイペースなアセットバンドルの更新と運用を支える技術について解説します。

エモモアイテムがユーザーに届くまでの流れ

Unityでのエモモアイテムのセットアップ、アセットバンドルのビルド、アセットバンドルの配信のフローによりエモモアイテムがユーザーに届けられます。

全体の概要は以下となっています。それぞれについて解説します。

f:id:t_sugaya:20220228120653p:plain:w300

1. エモモアイテムのセットアップ

3Dデザイナーがエモモのアイテムを以下のようにしてUnityプロジェクトに追加します。

  1. Mayaなどで3Dモデルを作成する
  2. Unity上で3Dモデルをミラティブアプリ向けにセットアップする
  3. Gitでアセット開発用ブランチにコミットする

3Dモデルを作成した後はUnity上で必要なコンポーネントを3Dモデルに付け、Unityエディタで動きを確認します。 動作の確認ができたら一連のアセットをGitでリポジトリに追加します。 リポジトリが更新されるとjenkinsのジョブが走り、以下のようなアセットの正常性チェックが行われます。問題がなければ次の工程に進みます。

  • アセットバンドルの依存関係が正しいか
  • テクスチャのフォーマットが正しいか
  • ディレクトリ構成が正しいか
  • アニメーションの容量が無駄に大きくなっていないか

f:id:t_sugaya:20220225141259p:plain:w300

チェック結果はSlackに通知され、どのアセットでエラーが起きているかが分かります。同様の機能はUnityエディタでも使えるようにしています。

2. アセットバンドルの作成

デザイナーが追加したアイテムをUnityエンジニアが一度チェックし、作りに問題ないかを確認してから以下の手順でアセットバンドルの作成まで行います。

  1. アセット開発用ブランチからFix用のブランチに向けてPRを作成する
  2. PRをマージし、リリース用ブランチに取り込む
  3. jenkinsで変更を検知しアセットバンドルをビルドする
  4. S3にアセットバンドルをアップロードする

アセットバンドル更新のPRはタイトルに[AssetBundle]のプレフィックスをつけて機能開発のPRと区別するようにしています。 また、アセットバンドル更新のPRではDangerによるPRの自動チェックが行われ、問題点や注意すべき変更が検知できるようになっています。 主なチェック項目としては

  • マージ先のブランチが正しいか
  • シェーダーなどの共通アセットに変更が入っているか
  • 追加・更新が行われたアセットを一覧化し、意図しない変更が入っていないか

などがあります。

f:id:t_sugaya:20220225140324p:plain:w300

DangerによるPRの自動チェック

PRのマージ後、アセットの更新をリリース用ブランチに取り込み、アセットバンドルのビルドを行います。

CI/CD専用のMac mini上にjenkinsを常時起動しており、そこでアセットバンドルをビルドしています。 SCMのポーリングで定期的に差分を検知し、変更があった場合のみビルドが行われます。

jenkinsによるアセットバンドルのビルドが行われると成果物がS3にアップロードされます。同時にアセットバンドルの成果物はバックアップ用のGitリポジトリにも追加しています。 開発用のアセットバンドルとユーザー向けのアセットバンドルは同じS3のバケットにアップロードし、どちらも同じアセットバンドルを使うことで更新の手間を減らし作業漏れが起こりにくくしています。

3.アセットバンドルの配信

アセットバンドルを作ったあとマスタを更新し使用するアセットバンドルを切り替えます。

  1. マスタで使用するアセットバンドルを指定する
  2. アプリでアセットバンドルのルートとなるURLをサーバーから受け取り、Unity製のフレームワークに送る
  3. フレームワークでは指定されたURLをもとにアセットバンドルをロードする

ミラティブのマスタはスプレッドシートで管理されており、GAS製のツールによりDBへのアセットバンドルマスタの反映が自動で行われます。 ミラティブはUnity as a Libraryを利用しているため、ネイティブアプリの中にUnity製のフレームワークが共存する形になっています。 ミラティブにおけるUnityフレームワークの仕組みについては以前の記事で紹介しています。 tech.mirrativ.stream ミラティブではUnityフレームワークがサーバーと直接通信することは避け、必ずネイティブアプリが仲介するようにしています。そのため、使用するアセットバンドルのルートURLもネイティブアプリがサーバーから受け取り、それをUnityフレームワークにSendMessageで渡すことで初期化を行っています。ただし、初期化以降の実際のアセットバンドルのダウンロードは、ルートURLを元にしてフレームワークが直接S3のバケットにアクセスし取得できるようにしています。

また、フレームワークのバージョンごとに使用するアセットバンドルのURLを変えられるようになっており、これによりアセットバンドルをバージョンごとに独立して更新できるため、過去のアプリバージョンであっても追加したエモモアイテムが使えるようになっています。ただし、サポートするフレームワークが増えるほどアセットバンドルのビルド回数や管理が難しくなるため、最新版のフレームワークが入ったアプリがリリースされてから3週間ほどで過去のバージョン分のサポートや更新は止めています。

f:id:t_sugaya:20220228123754p:plain:w500

ブランチの運用例です。リリース済みのフレームワークバージョンv1.0.0と新規リリースのフレームワークバージョンv2.0.0などの複数バージョンを独立して運用できるようにしています。FIX用ブランチの更新をv1.0.0とv2.0.0の両方に取り込み、それぞれのアセットバンドルを作成します。v2.0.0のバージョンがリリース後にv1.0.0の更新は終了します。

We are hiring!

効率的な運用のためには仕組み化や自動化が必須です。 現状ではまだまだテストは不足しており、デプロイにも時間がかかるなど多くの課題があります。 課題に向き合い続け、地道な改善や解決のための議論を日々行っています。 機能開発だけでなく、継続的な開発を支える技術に興味がある方も積極的に募集しています! www.mirrativ.co.jp