Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プリンセスコネクト!Re:Dive運用事例 ~リリースの高頻度化と安定化を両立させるプリコネR...

Cygames
September 06, 2019

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

2019/09/06 CEDEC 2019

Cygames

September 06, 2019
Tweet

More Decks by Cygames

Other Decks in Technology

Transcript

  1. 2/84 概要 • 本講演では、安定したプレイ環境を保ちつつ高頻度リリースを達 成するために、プリンセスコネクト!Re:Dive (以後プリコネ R)で行った取り組みについて紹介します。 • 新機能やイベント公開時のメンテナンスはユーザーのプレイ体験 を著しく阻害します。メンテナンスフリー実現のためには、リ

    ソースの下位互換を保つための仕組みと、複数ブランチに跨る大 量リソースの管理をサポートする体制が必要です。 • この体制を実現するためのアプリ設計手法、 CIを用いた大量の開 発ブランチの管理コスト改善事例について詳細に解説します。
  2. 3/84 Tomita Yasuyuki 冨田 康之 技術本部クライアントサイド ゲームエンジニア 大手コンシューマーゲーム開発会社を経て、 2014年より株式会社Cygamesに所属。 クライアントエンジニアとして

    ネイティブアプリ開発部署に従事。 「プリンセスコネクト!Re:Dive」では 開発からリリース・運用まで携わり アプリ開発やビルドシステム環境構築を 担当している。 自己紹介
  3. 8/84 3プラットフォーム リリースを どう安定させるか 大量の 開発ブランチを どう管理するか リリース時の アプリ互換性を どう維持するか

    リリース時のアプリ互換性を保つための設計 複数ブランチに跨る大量リソースの管理を サポート 3プラットフォーム向けリリースの安定化
  4. • 併存用のリソースもアップデート前後で互換性がなくなっていた ためアプリごとにURLを分けてダウンロードすることで対応。 26/84 Prefab アプリ リソース Unityアップデート時の対応 Unity2017 Ver

    Unity2018 Ver Unity2017 Prefab https://priconne/App2017/~ Unity2018用Prefab https://priconne/App2018/~ Unity2017用リソース https://priconne/Res2017/~ Unity2018用リソース https://priconne/Res2018/~ 2バージョン運用は管理が大変
  5. • Git-Flowをベースにした開発手法を採用 • develop … 開発の起点になるブランチ • feature … 個々の機能の開発ブランチ(devチェック)

    • release … リリース直前のブランチ(stagingチェック) • master … リリースされユーザーの手元に届いた相当の状態(本番部分) • hotfix … リリースデータ修正のためのブランチ(本番修正) 30/84 feature release develop master hotfix プリコネRでのGit運用
  6. 35/84 ブランチの数が爆発的に増加 • 1カ月の間、リリース用に用意するブランチ数はおよそ 10ブランチ × 5リポジトリ分 = 50ブランチ •

    開発中の依存関係を減らすべくリポジトリを分けたが、管理コス トが増大した リソース サウンド サーバー ムービー パラメータ
  7. プリコネR ブランチルールの例 ◼ masterにマージできるのは 「release」か「hotfix」のみ (それ以外はエラー) ◼ 数字が小さいものから大きいもの へのプルリクエストのみ許容 42/84

    • ブランチ命名規則から「マージNG」な伝播をシステムで弾く • ジョブ、プルリクエストhookでルールに沿っているかチェック ブランチ伝播の簡略化・事故防止
  8. 45/84 リソースをビルドするためのコスト • 日々の更新リソースは各プラットフォームで確認するためのリ ソースビルドが必要。 しかしリソースのビルドには時間がかかる。 1ブランチ当たり1~2時間 × 10ブランチ分 =

    最大20時間 • 複数のビルドマシンを用意して並列にビルドさせているが限界は ある。そのため、誰もいない夜間に時間のかかるビルドを動かし、 朝出社した時点で最新の状況を確認できるようにしておきたい。
  9. 47/84 • 構成を見直し、1つあたりの実行数を可変にするジョブを作成 • パラメータの変更で実行数を変更できるようにする ジョブ構成の見直し Windows iOS Android 3プラットフォーム

    ビルド(量産しない) 3プラットフォームビルドジョブ (このジョブが量産されていた) Windows iOS Android ジョブ実行数 可変ジョブ After Before
  10. 58/84 3プラットフォーム向けリリースの安定化 • プリコネRはiOS / Android / PC の3プラットフォームで運用され ているが、1カ月で更新するファイル数は合計5000ファイルを超

    える。この数になると、正しいファイルかのチェックにも時間が かかり高頻度リリースの妨げになるため効率化を図る必要がある。 • ビルドにかかる時間や不具合特定にかかる時間などは、本来の ゲーム開発にかけられる工数を圧迫し、運用の安定化を妨げる恐 れがあるため時間削減をしたい。 3プラットフォーム リリースを どう安定させるか
  11. 63/84 • AssetBundleをビルドするとキャッシュ情報として 「.manifest」というファイルも同時に出力される。 • .manifestファイルは毎回消していたので再利用するように – 作成したAssetBundleの出力パスと同パスに「. manifest」ファイルを配置 –

    Unityが差分を見てビルドの必要があるかを自動判断して対象ファイルを選別 .manifestキャッシュファイルの再利用 XXXX.unity3d XXXX.unity3d.manifest (このファイルを再利用) ビルドマシンでリソースXXXXをビルド
  12. 65/84 • 各リリース単位でフォルダ分けしてサーバーにアップロード – リソースビルド後、「.unity3d」と一緒に「.unity3d.manifest」もアップロード – 次回ビルド時に両ファイルをrsyncで全てダウンロード • 全ファイル1.3GBのダウンロードにかかる時間は約3分 –

    通信帯域によって時間は増減 リソースサーバーへアップロードして管理 2019/09/04 リリース用リソースフォルダ リソースサーバー 2019/09/06 リリース用リソースフォルダ ビルドマシン アップロード ダウンロード
  13. 74/84 • ルールは決めているが、どうしてもルールを破ったファイルが コミットされてしまうことがある。 – ファイルエクスプローラー上でコピー&ペーストしただけで、 Unity上でインポートせずにそのままプルリクエストを投げられてしまう – ファイル名にスペースが入ってしまう •

    プルリクエストの人力レビューではこれらを検知するのは難しく、 一度プルリクエストを通ってしまうと発見が遅れてしまい、対応 が難しくなってしまうことがある。 不正なmetaデータのコミット
  14. 76/84 • metaの存在チェック – コミット忘れ、消し忘れがないか • ファイル名チェック – 空白文字の有無 •

    metaのguid重複チェック – コピペで作成すると重複する • Materialファイル名とm_Nameプロパティが一致しているか – アセットバンドルのビルド結果が不定になる スクリプトで行っているチェックの詳細