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. プリンセスコネクト!Re:Dive 運用事例
    1/84
    ~リリースの高頻度化と安定化を両立させるプリコネRの運用体制~
    株式会社Cygames 冨田康之

    View full-size slide

  2. 2/84
    概要
    • 本講演では、安定したプレイ環境を保ちつつ高頻度リリースを達
    成するために、プリンセスコネクト!Re:Dive (以後プリコネ
    R)で行った取り組みについて紹介します。
    • 新機能やイベント公開時のメンテナンスはユーザーのプレイ体験
    を著しく阻害します。メンテナンスフリー実現のためには、リ
    ソースの下位互換を保つための仕組みと、複数ブランチに跨る大
    量リソースの管理をサポートする体制が必要です。
    • この体制を実現するためのアプリ設計手法、 CIを用いた大量の開
    発ブランチの管理コスト改善事例について詳細に解説します。

    View full-size slide

  3. 3/84
    Tomita Yasuyuki
    冨田 康之
    技術本部クライアントサイド
    ゲームエンジニア
    大手コンシューマーゲーム開発会社を経て、
    2014年より株式会社Cygamesに所属。
    クライアントエンジニアとして
    ネイティブアプリ開発部署に従事。
    「プリンセスコネクト!Re:Dive」では
    開発からリリース・運用まで携わり
    アプリ開発やビルドシステム環境構築を
    担当している。
    自己紹介

    View full-size slide

  4. 4/84
    プリコネRの基本情報
    • アニメRPGとして2018年2月15日リリース
    • iOS / Android / PC の3プラットフォームにて好評配信中

    View full-size slide

  5. 5/84
    プリコネRの開発情報
    • UnityとGit(GitHubEnterprise)による開発と運用
    • バイナリやリソースのビルドやデプロイはJenkinsによるCI
    • アプリのアップデートタイミングはおよそ1ヵ月に1~2回
    • サーバーやリソースのみのリリースは週に平均2回ほど。
    月合計でいうと1カ月あたり8回、繁忙期では1か月あたり10回を超える計画
    リリースが存在

    View full-size slide

  6. 6/84
    リリース前から決めていたこと
    • 毎週何かしらリリースを行う
    • 緊急の不具合修正を除き、通常の機能追加やアプリ更新で
    はメンテナンスに入らない
    ユーザーが安心して遊べるアプリの安定性と
    ユーザーに新たな驚きを提供し続けるための
    高頻度リリースとを両立させて提供できる体制が必要

    View full-size slide

  7. 3プラットフォーム
    リリースを
    どう安定させるか
    大量の
    開発ブランチを
    どう管理するか
    7/84
    この体制を実現するために解決すべき問題
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  8. 8/84
    3プラットフォーム
    リリースを
    どう安定させるか
    大量の
    開発ブランチを
    どう管理するか
    リリース時の
    アプリ互換性を
    どう維持するか
    リリース時のアプリ互換性を保つための設計
    複数ブランチに跨る大量リソースの管理を
    サポート
    3プラットフォーム向けリリースの安定化

    View full-size slide

  9. 9/84
    リリース時のアプリ互換性を保つための設計
    複数ブランチに跨る大量リソースの管理を
    サポート
    3プラットフォーム向けリリースの安定化
    アジェンダ

    View full-size slide

  10. 10/84
    リリース時のアプリ互換性を保つための設計
    アジェンダ

    View full-size slide

  11. 11/84
    リリース時のアプリ互換性を保つための設計
    • プリコネRでは通常の機能追加やアプリ更新ではメンテナンスに入
    らないということもリリース前から決めていた。
    • アプリ更新でメンテナンスに入らないということは、既にリリー
    ス済みのアプリバージョンやサーバー処理 / リソースと、互換性
    を持ちながら新しいアプリバージョンを公開する必要がある。
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  12. 12/84
    安定したプレイ環境を保つための基本方針
    • 先を見据えて新機能はあらかじめ先入れする
    • アプリのバージョン境界にて複数バージョンで動作を保証する
    • ストア申請リスクは可能な限り減らす
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  13. 13/84
    安定したプレイ環境を保つための基本方針
    • 先を見据えて新機能はあらかじめ先入れする
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  14. 14/84
    先を見据えて新機能はあらかじめ先入れする
    • 1回のアプリアップデートでアプリの中に可能な限り次の更新ま
    での機能を入れる(半月~一月分)。
    • 1度のメンテナンスで先々の分のDB更新も先行入れ込みすること
    でメンテ回数を可能な限り減らす。
    • 計画メンテナンスを行う際もお知らせした時間内で終わるように
    リハーサルを入念に行う。

    View full-size slide

  15. 15/84
    安定したプレイ環境を保つための基本方針
    • アプリのバージョン境界にて複数バージョンで動作を保証する
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  16. • アプリはユーザーが任意のタイミングでアップデートするため複
    数のバージョンが併存する期間が必ず存在する。
    • 並存期間中は新アプリは既にリリースされているリソースでも動
    く必要がある
    16/84
    機能を先入れする際に立ちはだかる壁
    アプリVer 1 公開期間
    公開済み
    リソース更新(併存期間リソース)
    8/15更新
    アプリVer 2 公開期間
    8/17公開
    併存期間 併存期間のリソースは
    互換性を保つ必要がある

    View full-size slide

  17. 17/84
    • 併存期間中に大型の機能解放を行うとサーバー処理やリソースとの下
    位互換が保てないことがある。
    • 併存期間中には大きい機能アップデートは行わないようにし、新機能
    は強制アップデート後に動き出すようにスケジュールを調整する。
    • ストアの浸透が終わる頃を見計らい強制アップデートを仕掛ける。
    アプリのバージョン境界問題

    View full-size slide

  18. 18/84
    アプリのバージョン境界問題
    • リソースデータはアプリのソースコードの影響を受けないデータ
    を開発段階から選別してダウンロードリソース化
    アプリVer 1
    併存期間リソース
    アプリVer 2
    併存期間 併存リソースデータ群
    ◆画像
    ◆パラメータ
    ◆アニメーションデータ
    ◆ムービー
    ◆サウンド
    etc...

    View full-size slide

  19. 19/84
    安定したプレイ環境を保つための基本方針
    • ストア申請リスクを可能な限り減らす
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  20. 20/84
    • 各プラットフォームのストア申請は、審査が通らずアプリがスケ
    ジュール通り出せなかったり、ストアへの反映に時間がかかる
    ケースなどがあるためリスクが大きい。
    • リソースをダウンロードするだけで更新できる幅を広げると、ス
    トア申請の回数が減ってリスクもコストも減る。プリコネRでは、
    ダウンロードリソースとして逃がせるものは逃がすようにしてい
    る。
    ストア申請のリスク

    View full-size slide

  21. 21/84
    UnityのPrefab問題
    • PrefabはUnityのソースコードの影響を受けるリソース
    – [SerializeField]のついたリソース
    • アプリ内蔵だとプレハブ修正時にストア申請リスクが発生

    View full-size slide

  22. 22/84
    UnityのPrefab問題
    • プリコネRではPrefabもダウンロードリソース化
    • Prefabのアタッチ外れ、GameObjectのActive ON/OFFがリ
    ソース更新で修正できるとメリットとして大きい

    View full-size slide

  23. • 開発フェーズではアプリに依存しないデータとみなしていた
    • アプリバージョンを跨ぐ際に互換性を維持できなくなる問題
    23/84
    Prefabのダウンロードリソース化(開発)
    アプリVer 1
    併存期間リソース
    アプリVer 2
    併存期間 併存リソースデータ群
    ■Prefab【危険】
    ◆画像
    ◆パラメータ
    ◆アニメーションデータ
    ◆ムービー
    etc...

    View full-size slide

  24. • 従来のURLとは別にPrefabリソース専用のURLをアプリバー
    ジョン毎に用意
    24/84
    Prefab
    アプリ
    リソース
    Prefabのダウンロードリソース化(運用)
    アプリVer 1 アプリVer 2
    併存期間リソース用URL
    Ver1用Prefab URL
    https://priconne/Ver1/~
    Ver2用Prefab URL
    https://priconne/Ver2/~

    View full-size slide

  25. • イベント前日に見つかったPrefab起因の不具合にも対応でき、ス
    トア申請によるスケジュールの変更リスクの軽減に貢献できた。
    25/84
    Prefab
    アプリ
    リソース
    Prefabのダウンロードリソース化(運用)
    アプリVer 1 アプリVer 2
    併存期間リソース用URL
    Ver1用Prefab URL
    https://priconne/Ver1/~
    Ver2用Prefab URL
    https://priconne/Ver2/~

    View full-size slide

  26. • 併存用のリソースもアップデート前後で互換性がなくなっていた
    ためアプリごとに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バージョン運用は管理が大変

    View full-size slide

  27. 27/84
    アプリ互換性を保つための設計 –まとめ–
    • プリコネRでは、最大限メンテナンスに入らないようにするための
    アプリの互換性を考慮した設計、およびスケジュールで運用が行
    われている。
    • アプリバージョン境界で互換性を保つために、ダウンロードする
    リソースやサーバー処理について特に気を配っている。
    リリース時の
    アプリ互換性を
    どう維持するか

    View full-size slide

  28. 28/84
    複数ブランチに跨る大量リソースの管理を
    サポート
    アジェンダ

    View full-size slide

  29. • プリコネRではGitによるバージョン管理を用いて開発と運用を進
    めている。しかし運用開始に伴い、日々の更新でリリースするた
    めのブランチの数と管理コストが爆発的に増えた。
    • ブランチ管理コストはゲーム開発にかけられる工数を圧迫し、安
    定運用を妨げる恐れがあるため、CIジョブによるサポートが必要。
    29/84
    複数ブランチに跨る大量リソースの管理
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  30. • Git-Flowをベースにした開発手法を採用
    • develop … 開発の起点になるブランチ
    • feature … 個々の機能の開発ブランチ(devチェック)
    • release … リリース直前のブランチ(stagingチェック)
    • master … リリースされユーザーの手元に届いた相当の状態(本番部分)
    • hotfix … リリースデータ修正のためのブランチ(本番修正)
    30/84
    feature
    release
    develop
    master
    hotfix
    プリコネRでのGit運用

    View full-size slide

  31. 31/84
    • developブランチをメインにしたシンプルな開発フロー
    • developからブランチを切りdevelopにプルリクエストを出すとい
    う分かりやすい開発フローだったため、特に混乱を生じることも
    なく開発が進んでいた
    feature 進捗レビュー用
    develop
    新規開発フェーズでのブランチ運用

    View full-size slide

  32. 32/84
    feature/2019_09_04 feature/2019_09_06
    release/2019_09_04 release/2019_09_06
    リリース直前にGit-Flowに準じた形へ
    • 運用後、よりGit-Flowに準じたフローへ移行
    • 本講演では例としてリリースする日付をブランチ名として採用
    – feature/2019_09_04 → release/2019_09_04
    – feature/2019_09_06 → release/2019_09_06
    develop
    master

    View full-size slide

  33. 33/84
    • 各スケジュールブランチから各機能ブランチが切られる
    • 1~2月先までのスケジュールのブランチが常に存在する
    ブランチの数が爆発的に増加
    各機能
    bugfix

    View full-size slide

  34. 34/84
    プリコネRのリリースに関わるリポジトリ
    • ファイル同士の依存関係を減らすため細分化した5個のリリース対
    応リポジトリが存在
    リソース サウンド
    サーバー
    ムービー
    パラメータ

    View full-size slide

  35. 35/84
    ブランチの数が爆発的に増加
    • 1カ月の間、リリース用に用意するブランチ数はおよそ
    10ブランチ × 5リポジトリ分 = 50ブランチ
    • 開発中の依存関係を減らすべくリポジトリを分けたが、管理コス
    トが増大した
    リソース サウンド
    サーバー
    ムービー
    パラメータ

    View full-size slide

  36. 36/84
    ブランチ管理コストの内訳
    • 各ブランチの変更を次のブランチへマージする作業の負担増加
    • 各ブランチリソースをビルドするためのCIジョブコストの増加
    • 各ブランチ内容を確認するための開発環境の管理コストの増加
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  37. 37/84
    JenkinsのCIによるブランチ管理コスト改善
    • これらブランチ管理コストの増加はJenkinsによるCIを用いて改
    善を図っていった。
    Jenkins
    CI(継続的インテグレーション)を実現するためのツール
    ビルドの自動化 開発コスト削減
    処理のひとかたまり
    をジョブと呼ぶ

    View full-size slide

  38. 38/84
    ブランチ管理コストの内訳
    • 各ブランチの変更を次のブランチへマージする作業の負担増加
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  39. 39/84
    • 「プリコネR」プロジェクト内での通称「ブランチの伝播」
    • 前のブランチの変更は次リリースのブランチでも必要になる
    – 例)2019_05_28の変更は2019_05_29【以降】のブランチへ取り込む必要が
    ある
    各ブランチの変更を次のブランチへマージ
    前のブランチの変更を
    次のブランチへ取り込む作業

    View full-size slide

  40. 40/84
    • 伝播方向を間違えるとブランチが破損する(予定外のリソースが混
    入したり、Revertで戻しきれなくなる)
    • 都度のマージ作業は単純だが、5リポジトリ合計50ブランチを毎
    回ミスなく伝播するのはとても難しく、失敗するとチーム全体の
    成果が吹っ飛ぶ
    各ブランチの変更を次のブランチへマージ

    View full-size slide

  41. 41/84
    • プルリクエスト作成用のCIジョブを作成
    – GitHubAPI 経由でJekinsからマージ元・先のブランチ名をパラメータを与える
    – ブランチ命名ルールは統一されているので5リポジトリ分一括で作成可能
    ブランチ伝播の簡略化・事故防止
    5リポジトリ分のプルリクエストを
    一気に作成する

    View full-size slide

  42. プリコネR ブランチルールの例
    ◼ masterにマージできるのは
    「release」か「hotfix」のみ
    (それ以外はエラー)
    ◼ 数字が小さいものから大きいもの
    へのプルリクエストのみ許容
    42/84
    • ブランチ命名規則から「マージNG」な伝播をシステムで弾く
    • ジョブ、プルリクエストhookでルールに沿っているかチェック
    ブランチ伝播の簡略化・事故防止

    View full-size slide

  43. 43/84
    • このジョブを作成後、ブランチ伝播による事故は撲滅できた。結
    果、伝播というデリケートな作業を効率的に安心して行えるよう
    になった。
    • ルールを破ったブランチ名を作られると事故は防げないが、マー
    ジ担当者を決めて勝手にはマージされないようにしている。
    • 自動マージ機能は破損ブランチが勝手に伝播されてしまうことを
    考慮して実装していない。
    ブランチ伝播の簡略化・事故防止

    View full-size slide

  44. 44/84
    ブランチ管理コストの内訳
    • 各ブランチリソースをビルドするためのCIジョブコストの増加
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  45. 45/84
    リソースをビルドするためのコスト
    • 日々の更新リソースは各プラットフォームで確認するためのリ
    ソースビルドが必要。 しかしリソースのビルドには時間がかかる。
    1ブランチ当たり1~2時間 × 10ブランチ分 = 最大20時間
    • 複数のビルドマシンを用意して並列にビルドさせているが限界は
    ある。そのため、誰もいない夜間に時間のかかるビルドを動かし、
    朝出社した時点で最新の状況を確認できるようにしておきたい。

    View full-size slide

  46. 46/84
    • 10ブランチ存在するので10ジョブ分発生する
    • ジョブを増産すると保守コストが後々大変なことになる
    自動ジョブの爆発的増加
    ブランチ指定などのパラメータが
    ありメンテナンスが困難
    ※記載のスケジュールは
    架空のものです

    View full-size slide

  47. 47/84
    • 構成を見直し、1つあたりの実行数を可変にするジョブを作成
    • パラメータの変更で実行数を変更できるようにする
    ジョブ構成の見直し
    Windows
    iOS
    Android
    3プラットフォーム
    ビルド(量産しない)
    3プラットフォームビルドジョブ
    (このジョブが量産されていた)
    Windows
    iOS
    Android
    ジョブ実行数 可変ジョブ
    After
    Before

    View full-size slide

  48. 48/84
    • Jenkinsの各ジョブはJenkinsfileというGroovyスクリプトで詳細
    に処理を組み立てることができる
    • 独自のセパレータ[-- ] (ハイフン二つ)を決めJenkinsfile内の処
    理でJenkinsに指定するパラメータを分割
    • 分割した各パラメータを下流のジョブに流す
    Jenkinsfileを用いてパラメータを工夫

    View full-size slide

  49. 49/84
    Jenkinsfileによるパラメータ分割の記述例

    View full-size slide

  50. 50/84
    • とても簡単なスクリプトだが効果は絶大。自動ジョブ系は1つだけ
    メンテナンスすればよく、ジョブ数増加による保守コストが激減。
    • パラメータ変更だけで良いのでエンジニア以外の職種も自動ジョ
    ブが整備できるようになった。
    • ビルド実行数を増やせるこの仕組みは、その他のジョブにも応用
    しやすくジョブ数の削減に貢献できた。
    自動ビルドをより設定しやすく改良

    View full-size slide

  51. 51/84
    ブランチ管理コストの内訳
    • 各ブランチ内容を確認するための開発環境の管理コストの増加
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  52. 52/84
    • プリコネRに存在する開発環境は40以上。各ブランチの内容を確
    認するには適切な環境への接続が必要になる。
    • どの環境に接続すれば各ブランチの作業内容が確認できるか、デ
    バッガやプランナーからは分かりづらく、混乱が発生した。
    • ホワイトボードやWiki管理していたが更新が頻繁でなく最新情報
    に保つのが難しい。各環境の状況は、可能な限り自動的に集めら
    れるようにしたい。
    開発確認環境の増加

    View full-size slide

  53. 53/84
    • 各開発環境へはブランチ名とデプロイ先のパラメータをJenkins実
    行時に指定する。この情報を流用したい。
    • デプロイはJenkinsが必須なため情報がジョブ内に集約されている
    サーバーへのデプロイジョブの情報を利用
    2019/09/04
    リリース向け対応
    開発サーバー
    2019/09/06
    リリース向け対応
    デプロイ
    パラメータ
    ・ブランチ名
    ・デプロイ先
    デプロイ
    デプロイ

    View full-size slide

  54. 54/84
    • 開発者が必ず行うデプロイ作業のパラメータを保存しておく
    • 保存しておいたパラメータを収集して常に最新の情報を自動表示
    デプロイ情報を利用してWebページ作成
    ・ブランチ名
    ・デプロイ先
    Jenkinsの情報を
    収集して表示

    View full-size slide

  55. 55/84
    • このWebページを作ることでプランナーやデバッガの混乱はなく
    なった。
    • 開発者の行動にフックしているため自動更新、保守も不要。
    デプロイ情報を利用してWebページ作成
    ・ブランチ名
    ・デプロイ先
    Jenkinsの情報を
    収集して表示

    View full-size slide

  56. 56/84
    複数ブランチ管理をサポート –まとめ–
    • プリコネRでは運用の結果、ブランチ数、及び管理コストが爆発的
    に増えた。
    • 主にブランチのマージコスト、ビルドコスト、各ブランチ開発環
    境の管理コストが増えていたため、JenkinsのCIジョブを調整す
    ることで開発をサポートし、高頻度なリリースにも耐えられる体
    制づくりに貢献。
    大量の
    開発ブランチを
    どう管理するか

    View full-size slide

  57. 57/84
    3プラットフォーム向けリリースの安定化
    アジェンダ

    View full-size slide

  58. 58/84
    3プラットフォーム向けリリースの安定化
    • プリコネRはiOS / Android / PC の3プラットフォームで運用され
    ているが、1カ月で更新するファイル数は合計5000ファイルを超
    える。この数になると、正しいファイルかのチェックにも時間が
    かかり高頻度リリースの妨げになるため効率化を図る必要がある。
    • ビルドにかかる時間や不具合特定にかかる時間などは、本来の
    ゲーム開発にかけられる工数を圧迫し、運用の安定化を妨げる恐
    れがあるため時間削減をしたい。
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  59. 59/84
    リリース安定化のための課題
    • リソースビルド時間の削減
    • リリースするファイルのチェック工数の削減
    • 上流工程での不正なファイル検出・バリデーション強化
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  60. 60/84
    リリース安定化のための課題
    • リソースビルド時間の削減
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  61. 61/84
    • 日々の更新リソースは各プラットフォームで確認するためのビル
    ドが必要。リリース当初は全リソース20分程度で終了していた。
    • 運用による更新が積み重なった結果、1年間で1プラットフォーム
    あたり1万ファイルほどリソースファイルが増加した。その結果、
    運用1年あたりでフルビルド1時間までビルド時間が増大した。
    • 途中からリリースしたPC版に至ってはビルド時間が2時間を突破
    し、開発のイテレーションに支障を来す事態に発展。
    リソースのビルド時間の増大

    View full-size slide

  62. 62/84
    • 変更が予めわかっていればカテゴリ指定の方がはるかに速いため、
    データをカテゴリ分けしてビルドする仕組みを作っていた。
    • 運用によりファイルが増え、カテゴリ別でのビルドでさえ時間が
    かかるようになった。変更がないファイルも毎回ビルドして時間
    がかかっていたので変更分だけをビルドしたい。
    カテゴリ毎に分割してビルド
    パラメータデータ
    キャラクターデータ
    パラメーターのみ変更したのであれば
    パラメータカテゴリのみビルドすればよい

    View full-size slide

  63. 63/84
    • AssetBundleをビルドするとキャッシュ情報として
    「.manifest」というファイルも同時に出力される。
    • .manifestファイルは毎回消していたので再利用するように
    – 作成したAssetBundleの出力パスと同パスに「. manifest」ファイルを配置
    – Unityが差分を見てビルドの必要があるかを自動判断して対象ファイルを選別
    .manifestキャッシュファイルの再利用
    XXXX.unity3d
    XXXX.unity3d.manifest
    (このファイルを再利用)
    ビルドマシンでリソースXXXXをビルド

    View full-size slide

  64. 64/84
    • ビルドマシンに消さずに残したまま次回ビルドに利用
    – 前回ビルドの影響を大きく受けビルド時間が安定しない可能性があるので却下
    • Gitで管理して再利用
    – サイズが大きく社内のGitHubEnterpriseサーバーを圧迫するので却下
    .manifestファイルの管理問題
    ビルドマシンに残す
    前のビルド結果に左右される
    XX.unity3d
    XX.unity3d.manifest
    Gitによる差分管理
    GHEサーバーを圧迫
    XX.unity3d
    XX.unity3d.manifest

    View full-size slide

  65. 65/84
    • 各リリース単位でフォルダ分けしてサーバーにアップロード
    – リソースビルド後、「.unity3d」と一緒に「.unity3d.manifest」もアップロード
    – 次回ビルド時に両ファイルをrsyncで全てダウンロード
    • 全ファイル1.3GBのダウンロードにかかる時間は約3分
    – 通信帯域によって時間は増減
    リソースサーバーへアップロードして管理
    2019/09/04
    リリース用リソースフォルダ
    リソースサーバー
    2019/09/06
    リリース用リソースフォルダ
    ビルドマシン
    アップロード
    ダウンロード

    View full-size slide

  66. 66/84
    • 1時間超のビルドがダウンロード時間を含め30分程度にまで短縮
    – 前回のビルド結果からの差分が多いとビルド時間は増加
    – 初回ビルドは時間がかかるが既存のリソースをコピーすれば時間は大幅に短縮
    – リソースをコピーするだけのジョブも作成
    .manifestファイルの管理問題
    2019/09/04
    リリース用リソースフォルダ
    リソースサーバー 2019/09/06
    不具合修正用リソース
    (9/6分からコピー)
    2019/09/06
    リリース用リソースフォルダ
    ジョブによる
    リソースフォルダコピー

    View full-size slide

  67. 67/84
    リリース安定化のための課題
    • リリースするファイルのチェック工数の削減
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  68. 68/84
    • 先のスケジュールのデータやテストデータが混入した状態でリ
    リースしてしまうと、ユーザーへのネタバレリスクが高まったり、
    深刻な不具合につながる。リリース直前のファイル差分チェック
    は安定リリースに必須といえる作業。
    • パラメータや画像は一目で未公開データだと判別しやすくネット
    上で拡散されてしまうリスクがあるため、先のスケジュールの
    データが間違って混入していないかは特に重視してチェックする。
    リリース直前でのチェック

    View full-size slide

  69. 69/84
    • 基本は各リポジトリに対するGitによるdiffを用いたチェックを行
    うが、1ヶ月に8回~10回行われるリリースで更新されるファ
    イルの合計は3プラットフォームで5000個を超える。
    • 月中・月末などのイベント更新は、1回のリリースで1000個以上
    のファイルを更新することもある。更新ファイルが非常に多いた
    め、チェックにかける工数は少しでも削減したい。
    • リソースリポジトリ内の画像ファイルに関しては
    画像ファイルのみを抽出してdiffを出し確認するように
    ファイルのチェック工数問題

    View full-size slide

  70. 70/84
    • ブランチ同士を比較して差分を出すだけのジョブを作成
    • パラメータと画像のみの差分をまとめて出せるように
    • 毎朝自動でまとめて差分をチェックし、 botで社内SNSに通知
    – 毎日どういう差分が出ているか確認
    – 自動ビルドのJenkinsfileを応用して1ジョブで全リリースの通知設定が完結
    差分確認に集中できるジョブを作成

    View full-size slide

  71. 71/84
    • DSL(Domain Specific Language)でのパラメータ検証システム
    も併用
    • 詳細はCEDEC2017の弊社発表資料を参照
    • http://tech.cygames.co.jp/archives/3048/
    DSLによるパラメータ整合性チェック

    View full-size slide

  72. 72/84
    リリース安定化のための課題
    • 上流工程での不正なファイル検出・バリデーション強化
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  73. 73/84
    • プリコネRではデザイナー・プランナーが自身で作成したデータを
    Gitでコミットし、プルリクエストを作るところまで対応。開発段
    階からGitに触れてもらうことで慣れてもらった。
    • 少しでも分からないところや行き詰ったところがあった場合は都
    度相談に乗る形で、エンジニアが全力でサポート。
    • 各データコミットを各セクションにお願いできたため、エンジニ
    ア負担は減ったが、不正なデータのコミットも増えた。
    他職種によるGit操作

    View full-size slide

  74. 74/84
    • ルールは決めているが、どうしてもルールを破ったファイルが
    コミットされてしまうことがある。
    – ファイルエクスプローラー上でコピー&ペーストしただけで、
    Unity上でインポートせずにそのままプルリクエストを投げられてしまう
    – ファイル名にスペースが入ってしまう
    • プルリクエストの人力レビューではこれらを検知するのは難しく、
    一度プルリクエストを通ってしまうと発見が遅れてしまい、対応
    が難しくなってしまうことがある。
    不正なmetaデータのコミット

    View full-size slide

  75. 75/84
    • 独自のチェックスクリプトを作成し、プルリクエストにひっかけ
    てmetaファイルをチェック。
    • Unityのアセットファイルは一般的なyml形式ファイルで記述され
    ているため、yml形式ファイルをロードできるスクリプトを用い
    れば簡単な解析は可能(プリコネRではpythonを使用)
    metaファイルに対するバリデーションを強化
    データ作成
    コミット
    プルリクエスト マージ ビルド デバッグ 本番
    不正なファイルはここで食い止めたい

    View full-size slide

  76. 76/84
    • metaの存在チェック
    – コミット忘れ、消し忘れがないか
    • ファイル名チェック
    – 空白文字の有無
    • metaのguid重複チェック
    – コピペで作成すると重複する
    • Materialファイル名とm_Nameプロパティが一致しているか
    – アセットバンドルのビルド結果が不定になる
    スクリプトで行っているチェックの詳細

    View full-size slide

  77. 79/84
    • 本バリデーションを入れた結果、単純なデータ不整合エラーはほ
    ぼ撲滅することに成功。
    • プルリクエストでのバリデーションはイテレーション速度重視で、
    チェックしたい内容を取捨選択。全ての不整合をチェックできる
    のがベストだが、厚くすると1プルリクエスト当たりのチェック時
    間が2時間を越えてしまった。チェック内容を取捨選択してこれを
    2分にまで短縮。
    バリデーション速度とイテレーション速度

    View full-size slide

  78. 80/84
    リリースの安定化 –まとめ–
    • プリコネRでは1カ月あたり合計5000ファイルを超える更新ファ
    イルを安定化させるべく、更新ファイルのチェックにかかる時間
    やビルドにかかる時間を削減する取り組みをしている。
    • 安定化を妨げる不正なデータは上流工程から検出、除去すること
    でデータ不整合系のエラーは発生させないようにしている。
    3プラットフォーム
    リリースを
    どう安定させるか

    View full-size slide

  79. まとめ
    81/84

    View full-size slide

  80. 82/84
    本講演のまとめ
    • プリコネRでは、互換性を保つアプリ/リソース設計やスケジュー
    ルの管理を行うことで、アプリ更新時にもメンテナンスフリーな
    運用を実現できました。
    • CIを用いた大量の開発ブランチの管理コスト改善や、ビルド時間
    の削減、バリデーションの強化を行うことで、リリースの安定化
    を行いつつ高頻度なリリースにも耐えられる体制を構築しました。

    View full-size slide

  81. 83/84
    • メンテナンスフリーに更新できる体制は、ユーザーがいつでもプ
    レイできる環境を提供するためです。
    • 効率化や自動化、リリース前チェックを徹底しているのも、日々
    行われるリリース作業を安定化させるためです。リリースが安定
    することで運用への信頼度が上がり、結果としてユーザーが常に
    安心してプレイできる環境へとつながります。
    全てはユーザーの為に

    View full-size slide

  82. 84/84
    最後に
    開発スタッフは
    プリコネが大好きです!

    View full-size slide