【CEDEC 2019 フォローアップ】プリンセスコネクト!Re:Dive 運用事例 ~リリースの高頻度化と安定化を両立させるプリコネRの運用体制~


皆さまこんにちは。Cygamesでクライントサイドエンジニアを務めている冨田と申します。2019年9月6日(金)に開催されたCEDEC 2019にて、「プリンセスコネクト!Re:Dive 運用事例 ~リリースの高頻度化と安定化を両立させるプリコネRの運用体制~」という題名で講演を行いました。聴講いただいた方々には改めてお礼申し上げます。

今回は講演資料の公開と、講演後にいくつか質問をいただきましたので、フォローアップという形でご返答させていただきます。

資料の公開

当日の講演資料は下記となります。

Q: アプリバージョンごとにPrefabダウンロード専用のURLを用意しているとのことでしたが、アプリバージョンの切り替わりによって全リソースの再ダウンロードなどは発生しないのですか?

A: アプリバージョンが変わっても全リソースの再ダウンロードが発生しないよう、ファイル内容に差分がある場合のみリソース再ダウンロードが行われる処理をアプリ側に組んであります。講演ではスライド表示の都合上割愛しましたが、アセットバンドル名まで含めたダウンロードURLは下記のようになります。

https://priconne/Ver1/assetbundle_a
https://priconne/Ver2/assetbundle_a

「Ver1」「Ver2」部分はユーザーがインストールしているアプリのバージョンに応じて変わるため、結果ダウンロードURLも変わります。上記URLのようにVer1、Ver2にも「assetbundle_a」というリソースが存在していた場合、アプリアップデート時にこの「assetbundle_a」リソースを再ダウンロードするか否かは、同じ階層に配置している「resource_filelist」というファイルを基に決めています。

https://priconne/Ver1/resource_filelist
https://priconne/Ver2/resource_filelist

このファイル内には「ファイル名とファイルハッシュ値」を組みにした情報がリスト形式で保存されており、アプリはまずこのファイルをダウンロードしてきます。一度もダウンロードされていないファイルの場合は通常通りダウンロードを行い、既にダウンロード済みのファイルの場合はファイルハッシュ値に差分があった場合のみファイルをダウンロードしなおすようにアプリ側で処理が組まれています。「既にダウンロード済みか? 最後にダウンロードしたファイルのファイルハッシュ値は何か?」という情報はアプリ側のローカルストレージに別途保存して管理しています。

※URLやファイル名は全て架空のものです。

※当日いただいた質問への回答にて「アプリバージョンが上がるとアセットバンドル名も変わる」と返答してしまいましたが、こちら回答に誤りがありました、大変申し訳ありません。URLアドレス上でアプリバージョンが上がると変わるのは、上記URLの「Ver1」「Ver2」の部分だけで、アセットバンドル名は変わりません。

Q: ブランチのマージ作業全般は誰がどのように管理を行っていますか?

A: 「リリース管理」という専任者を立ててマージ対応をしています。スライド内では「マージ担当者」という形で紹介していますが、実際にはブランチのマージに留まらず、ブランチ運用に関係するあらゆる作業を担当しています。開発全体を俯瞰し、進捗管理を行うのが「リリース管理」の主な作業です。具体的には、各種機能開発や不具合修正のスケジュール管理にはじまり、新規リリース用のブランチ作成、後続のリリース用ブランチへの伝播マージ、stagingチェックでのリソースビルドやサーバーデプロイ、などが作業内容として挙げられます。今回の講演でご紹介した様々な自動化・効率化は、実はこの「リリース管理」の負荷を減らすための取り組みも含んでいます。しかし、イベント開催時などの繁忙期には作業負荷が集中しやすいポジションでもあるため、マージ作業などを持ち回りで担当することもあります。


Q. Unityアップデート時のアプリ更新もメンテナンスフリーで行ったのですか?

A: はい、スライドでも紹介しているようにPrefabリソース、通常リソース、ともにUnity2017用、Unity2018用の2バージョンリソースを用意し、Unityアップデート対応を含んだアプリ更新もメンテナンスフリーで行いました。しかし、通常リソース側も2バージョン存在する状態での運用は、大量のリソースがどちらのバージョンにもきちんと過不足なく存在しているか(マージ漏れ等はないか)というブランチ管理上の問題や、本番環境へのリリースフローの複雑化など様々な困難が生じるため、こういった2バージョン管理状態は可能な限り回避する方針を取っています。

以上、いただいたご質問への返答となります。
みなさまのご参考になれば幸いです。