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

2019/09/06 CEDEC 2019

Transcript

1. プリンセスコネクト！Re:Dive 運用事例 1/84 ～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～ 株式会社Cygames 冨田康之
2. 2/84 概要 • 本講演では、安定したプレイ環境を保ちつつ高頻度リリースを達 成するために、プリンセスコネクト！Re:Dive （以後プリコネ R）で行った取り組みについて紹介します。 • 新機能やイベント公開時のメンテナンスはユーザーのプレイ体験 を著しく阻害します。メンテナンスフリー実現のためには、リ ソースの下位互換を保つための仕組みと、複数ブランチに跨る大 量リソースの管理をサポートする体制が必要です。 • この体制を実現するためのアプリ設計手法、 CIを用いた大量の開 発ブランチの管理コスト改善事例について詳細に解説します。
3. 3/84 Tomita Yasuyuki 冨田 康之 技術本部クライアントサイド ゲームエンジニア 大手コンシューマーゲーム開発会社を経て、 2014年より株式会社Cygamesに所属。 クライアントエンジニアとして ネイティブアプリ開発部署に従事。 「プリンセスコネクト！Re:Dive」では 開発からリリース・運用まで携わり アプリ開発やビルドシステム環境構築を 担当している。 自己紹介
4. 4/84 プリコネRの基本情報 • アニメRPGとして2018年2月15日リリース • iOS / Android / PC の3プラットフォームにて好評配信中
5. 5/84 プリコネRの開発情報 • UnityとGit（GitHubEnterprise）による開発と運用 • バイナリやリソースのビルドやデプロイはJenkinsによるCI • アプリのアップデートタイミングはおよそ１ヵ月に1～2回 • サーバーやリソースのみのリリースは週に平均２回ほど。 月合計でいうと1カ月あたり8回、繁忙期では1か月あたり10回を超える計画 リリースが存在
6. 6/84 リリース前から決めていたこと • 毎週何かしらリリースを行う • 緊急の不具合修正を除き、通常の機能追加やアプリ更新で はメンテナンスに入らない ユーザーが安心して遊べるアプリの安定性と ユーザーに新たな驚きを提供し続けるための 高頻度リリースとを両立させて提供できる体制が必要
7. 3プラットフォーム リリースを どう安定させるか 大量の 開発ブランチを どう管理するか 7/84 この体制を実現するために解決すべき問題 リリース時の アプリ互換性を どう維持するか
8. 8/84 3プラットフォーム リリースを どう安定させるか 大量の 開発ブランチを どう管理するか リリース時の アプリ互換性を どう維持するか リリース時のアプリ互換性を保つための設計 複数ブランチに跨る大量リソースの管理を サポート 3プラットフォーム向けリリースの安定化
9. 9/84 リリース時のアプリ互換性を保つための設計 複数ブランチに跨る大量リソースの管理を サポート 3プラットフォーム向けリリースの安定化 アジェンダ
10. 10/84 リリース時のアプリ互換性を保つための設計 アジェンダ
11. 11/84 リリース時のアプリ互換性を保つための設計 • プリコネRでは通常の機能追加やアプリ更新ではメンテナンスに入 らないということもリリース前から決めていた。 • アプリ更新でメンテナンスに入らないということは、既にリリー ス済みのアプリバージョンやサーバー処理 / リソースと、互換性 を持ちながら新しいアプリバージョンを公開する必要がある。 リリース時の アプリ互換性を どう維持するか
12. 12/84 安定したプレイ環境を保つための基本方針 • 先を見据えて新機能はあらかじめ先入れする • アプリのバージョン境界にて複数バージョンで動作を保証する • ストア申請リスクは可能な限り減らす リリース時の アプリ互換性を どう維持するか
13. 13/84 安定したプレイ環境を保つための基本方針 • 先を見据えて新機能はあらかじめ先入れする リリース時の アプリ互換性を どう維持するか
14. 14/84 先を見据えて新機能はあらかじめ先入れする • １回のアプリアップデートでアプリの中に可能な限り次の更新ま での機能を入れる（半月～一月分）。 • 1度のメンテナンスで先々の分のDB更新も先行入れ込みすること でメンテ回数を可能な限り減らす。 • 計画メンテナンスを行う際もお知らせした時間内で終わるように リハーサルを入念に行う。
15. 15/84 安定したプレイ環境を保つための基本方針 • アプリのバージョン境界にて複数バージョンで動作を保証する リリース時の アプリ互換性を どう維持するか
16. • アプリはユーザーが任意のタイミングでアップデートするため複 数のバージョンが併存する期間が必ず存在する。 • 並存期間中は新アプリは既にリリースされているリソースでも動 く必要がある 16/84 機能を先入れする際に立ちはだかる壁 アプリVer 1 公開期間 公開済み リソース更新(併存期間リソース) 8/15更新 アプリVer 2 公開期間 8/17公開 併存期間 併存期間のリソースは 互換性を保つ必要がある
17. 17/84 • 併存期間中に大型の機能解放を行うとサーバー処理やリソースとの下 位互換が保てないことがある。 • 併存期間中には大きい機能アップデートは行わないようにし、新機能 は強制アップデート後に動き出すようにスケジュールを調整する。 • ストアの浸透が終わる頃を見計らい強制アップデートを仕掛ける。 アプリのバージョン境界問題
18. 18/84 アプリのバージョン境界問題 • リソースデータはアプリのソースコードの影響を受けないデータ を開発段階から選別してダウンロードリソース化 アプリVer 1 併存期間リソース アプリVer 2 併存期間 併存リソースデータ群 ◆画像 ◆パラメータ ◆アニメーションデータ ◆ムービー ◆サウンド etc...
19. 19/84 安定したプレイ環境を保つための基本方針 • ストア申請リスクを可能な限り減らす リリース時の アプリ互換性を どう維持するか
20. 20/84 • 各プラットフォームのストア申請は、審査が通らずアプリがスケ ジュール通り出せなかったり、ストアへの反映に時間がかかる ケースなどがあるためリスクが大きい。 • リソースをダウンロードするだけで更新できる幅を広げると、ス トア申請の回数が減ってリスクもコストも減る。プリコネRでは、 ダウンロードリソースとして逃がせるものは逃がすようにしてい る。 ストア申請のリスク
21. 21/84 UnityのPrefab問題 • PrefabはUnityのソースコードの影響を受けるリソース – [SerializeField]のついたリソース • アプリ内蔵だとプレハブ修正時にストア申請リスクが発生
22. 22/84 UnityのPrefab問題 • プリコネRではPrefabもダウンロードリソース化 • Prefabのアタッチ外れ、GameObjectのActive ON/OFFがリ ソース更新で修正できるとメリットとして大きい
23. • 開発フェーズではアプリに依存しないデータとみなしていた • アプリバージョンを跨ぐ際に互換性を維持できなくなる問題 23/84 Prefabのダウンロードリソース化(開発) アプリVer 1 併存期間リソース アプリVer 2 併存期間 併存リソースデータ群 ▪Prefab【危険】 ◆画像 ◆パラメータ ◆アニメーションデータ ◆ムービー etc...
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/~
25. • イベント前日に見つかったPrefab起因の不具合にも対応でき、ス トア申請によるスケジュールの変更リスクの軽減に貢献できた。 25/84 Prefab アプリ リソース Prefabのダウンロードリソース化（運用） アプリVer 1 アプリVer 2 併存期間リソース用URL Ver1用Prefab URL https://priconne/Ver1/~ Ver2用Prefab URL https://priconne/Ver2/~
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バージョン運用は管理が大変
27. 27/84 アプリ互換性を保つための設計 –まとめ– • プリコネRでは、最大限メンテナンスに入らないようにするための アプリの互換性を考慮した設計、およびスケジュールで運用が行 われている。 • アプリバージョン境界で互換性を保つために、ダウンロードする リソースやサーバー処理について特に気を配っている。 リリース時の アプリ互換性を どう維持するか
28. 28/84 複数ブランチに跨る大量リソースの管理を サポート アジェンダ
29. • プリコネRではGitによるバージョン管理を用いて開発と運用を進 めている。しかし運用開始に伴い、日々の更新でリリースするた めのブランチの数と管理コストが爆発的に増えた。 • ブランチ管理コストはゲーム開発にかけられる工数を圧迫し、安 定運用を妨げる恐れがあるため、CIジョブによるサポートが必要。 29/84 複数ブランチに跨る大量リソースの管理 大量の 開発ブランチを どう管理するか
30. • Git-Flowをベースにした開発手法を採用 • develop … 開発の起点になるブランチ • feature … 個々の機能の開発ブランチ（devチェック） • release … リリース直前のブランチ（stagingチェック） • master … リリースされユーザーの手元に届いた相当の状態（本番部分） • hotfix … リリースデータ修正のためのブランチ（本番修正） 30/84 feature release develop master hotfix プリコネRでのGit運用
31. 31/84 • developブランチをメインにしたシンプルな開発フロー • developからブランチを切りdevelopにプルリクエストを出すとい う分かりやすい開発フローだったため、特に混乱を生じることも なく開発が進んでいた feature 進捗レビュー用 develop 新規開発フェーズでのブランチ運用
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
33. 33/84 • 各スケジュールブランチから各機能ブランチが切られる • 1～2月先までのスケジュールのブランチが常に存在する ブランチの数が爆発的に増加 各機能 bugfix
34. 34/84 プリコネRのリリースに関わるリポジトリ • ファイル同士の依存関係を減らすため細分化した5個のリリース対 応リポジトリが存在 リソース サウンド サーバー ムービー パラメータ
35. 35/84 ブランチの数が爆発的に増加 • １カ月の間、リリース用に用意するブランチ数はおよそ 10ブランチ × 5リポジトリ分 = 50ブランチ • 開発中の依存関係を減らすべくリポジトリを分けたが、管理コス トが増大した リソース サウンド サーバー ムービー パラメータ
36. 36/84 ブランチ管理コストの内訳 • 各ブランチの変更を次のブランチへマージする作業の負担増加 • 各ブランチリソースをビルドするためのCIジョブコストの増加 • 各ブランチ内容を確認するための開発環境の管理コストの増加 大量の 開発ブランチを どう管理するか
37. 37/84 JenkinsのCIによるブランチ管理コスト改善 • これらブランチ管理コストの増加はJenkinsによるCIを用いて改 善を図っていった。 Jenkins CI(継続的インテグレーション)を実現するためのツール ビルドの自動化 開発コスト削減 処理のひとかたまり をジョブと呼ぶ
38. 38/84 ブランチ管理コストの内訳 • 各ブランチの変更を次のブランチへマージする作業の負担増加 大量の 開発ブランチを どう管理するか
39. 39/84 • 「プリコネR」プロジェクト内での通称「ブランチの伝播」 • 前のブランチの変更は次リリースのブランチでも必要になる – 例）2019_05_28の変更は2019_05_29【以降】のブランチへ取り込む必要が ある 各ブランチの変更を次のブランチへマージ 前のブランチの変更を 次のブランチへ取り込む作業
40. 40/84 • 伝播方向を間違えるとブランチが破損する(予定外のリソースが混 入したり、Revertで戻しきれなくなる） • 都度のマージ作業は単純だが、５リポジトリ合計50ブランチを毎 回ミスなく伝播するのはとても難しく、失敗するとチーム全体の 成果が吹っ飛ぶ 各ブランチの変更を次のブランチへマージ
41. 41/84 • プルリクエスト作成用のCIジョブを作成 – GitHubAPI 経由でJekinsからマージ元・先のブランチ名をパラメータを与える – ブランチ命名ルールは統一されているので5リポジトリ分一括で作成可能 ブランチ伝播の簡略化・事故防止 ５リポジトリ分のプルリクエストを 一気に作成する
42. プリコネR ブランチルールの例 ◼ masterにマージできるのは 「release」か「hotfix」のみ (それ以外はエラー) ◼ 数字が小さいものから大きいもの へのプルリクエストのみ許容 42/84 • ブランチ命名規則から「マージNG」な伝播をシステムで弾く • ジョブ、プルリクエストhookでルールに沿っているかチェック ブランチ伝播の簡略化・事故防止
43. 43/84 • このジョブを作成後、ブランチ伝播による事故は撲滅できた。結 果、伝播というデリケートな作業を効率的に安心して行えるよう になった。 • ルールを破ったブランチ名を作られると事故は防げないが、マー ジ担当者を決めて勝手にはマージされないようにしている。 • 自動マージ機能は破損ブランチが勝手に伝播されてしまうことを 考慮して実装していない。 ブランチ伝播の簡略化・事故防止
44. 44/84 ブランチ管理コストの内訳 • 各ブランチリソースをビルドするためのCIジョブコストの増加 大量の 開発ブランチを どう管理するか
45. 45/84 リソースをビルドするためのコスト • 日々の更新リソースは各プラットフォームで確認するためのリ ソースビルドが必要。 しかしリソースのビルドには時間がかかる。 １ブランチ当たり１～２時間 × 10ブランチ分 ＝ 最大20時間 • 複数のビルドマシンを用意して並列にビルドさせているが限界は ある。そのため、誰もいない夜間に時間のかかるビルドを動かし、 朝出社した時点で最新の状況を確認できるようにしておきたい。
46. 46/84 • 10ブランチ存在するので10ジョブ分発生する • ジョブを増産すると保守コストが後々大変なことになる 自動ジョブの爆発的増加 ブランチ指定などのパラメータが ありメンテナンスが困難 ※記載のスケジュールは 架空のものです
47. 47/84 • 構成を見直し、1つあたりの実行数を可変にするジョブを作成 • パラメータの変更で実行数を変更できるようにする ジョブ構成の見直し Windows iOS Android 3プラットフォーム ビルド(量産しない) 3プラットフォームビルドジョブ (このジョブが量産されていた) Windows iOS Android ジョブ実行数 可変ジョブ After Before
48. 48/84 • Jenkinsの各ジョブはJenkinsfileというGroovyスクリプトで詳細 に処理を組み立てることができる • 独自のセパレータ[-- ] （ハイフン二つ）を決めJenkinsfile内の処 理でJenkinsに指定するパラメータを分割 • 分割した各パラメータを下流のジョブに流す Jenkinsfileを用いてパラメータを工夫
49. 49/84 Jenkinsfileによるパラメータ分割の記述例
50. 50/84 • とても簡単なスクリプトだが効果は絶大。自動ジョブ系は1つだけ メンテナンスすればよく、ジョブ数増加による保守コストが激減。 • パラメータ変更だけで良いのでエンジニア以外の職種も自動ジョ ブが整備できるようになった。 • ビルド実行数を増やせるこの仕組みは、その他のジョブにも応用 しやすくジョブ数の削減に貢献できた。 自動ビルドをより設定しやすく改良
51. 51/84 ブランチ管理コストの内訳 • 各ブランチ内容を確認するための開発環境の管理コストの増加 大量の 開発ブランチを どう管理するか
52. 52/84 • プリコネRに存在する開発環境は40以上。各ブランチの内容を確 認するには適切な環境への接続が必要になる。 • どの環境に接続すれば各ブランチの作業内容が確認できるか、デ バッガやプランナーからは分かりづらく、混乱が発生した。 • ホワイトボードやWiki管理していたが更新が頻繁でなく最新情報 に保つのが難しい。各環境の状況は、可能な限り自動的に集めら れるようにしたい。 開発確認環境の増加
53. 53/84 • 各開発環境へはブランチ名とデプロイ先のパラメータをJenkins実 行時に指定する。この情報を流用したい。 • デプロイはJenkinsが必須なため情報がジョブ内に集約されている サーバーへのデプロイジョブの情報を利用 2019/09/04 リリース向け対応 開発サーバー 2019/09/06 リリース向け対応 デプロイ パラメータ ・ブランチ名 ・デプロイ先 デプロイ デプロイ
54. 54/84 • 開発者が必ず行うデプロイ作業のパラメータを保存しておく • 保存しておいたパラメータを収集して常に最新の情報を自動表示 デプロイ情報を利用してWebページ作成 ・ブランチ名 ・デプロイ先 Jenkinsの情報を 収集して表示
55. 55/84 • このWebページを作ることでプランナーやデバッガの混乱はなく なった。 • 開発者の行動にフックしているため自動更新、保守も不要。 デプロイ情報を利用してWebページ作成 ・ブランチ名 ・デプロイ先 Jenkinsの情報を 収集して表示
56. 56/84 複数ブランチ管理をサポート –まとめ– • プリコネRでは運用の結果、ブランチ数、及び管理コストが爆発的 に増えた。 • 主にブランチのマージコスト、ビルドコスト、各ブランチ開発環 境の管理コストが増えていたため、JenkinsのCIジョブを調整す ることで開発をサポートし、高頻度なリリースにも耐えられる体 制づくりに貢献。 大量の 開発ブランチを どう管理するか
57. 57/84 3プラットフォーム向けリリースの安定化 アジェンダ
58. 58/84 3プラットフォーム向けリリースの安定化 • プリコネRはiOS / Android / PC の3プラットフォームで運用され ているが、１カ月で更新するファイル数は合計5000ファイルを超 える。この数になると、正しいファイルかのチェックにも時間が かかり高頻度リリースの妨げになるため効率化を図る必要がある。 • ビルドにかかる時間や不具合特定にかかる時間などは、本来の ゲーム開発にかけられる工数を圧迫し、運用の安定化を妨げる恐 れがあるため時間削減をしたい。 3プラットフォーム リリースを どう安定させるか
59. 59/84 リリース安定化のための課題 • リソースビルド時間の削減 • リリースするファイルのチェック工数の削減 • 上流工程での不正なファイル検出・バリデーション強化 3プラットフォーム リリースを どう安定させるか
60. 60/84 リリース安定化のための課題 • リソースビルド時間の削減 3プラットフォーム リリースを どう安定させるか
61. 61/84 • 日々の更新リソースは各プラットフォームで確認するためのビル ドが必要。リリース当初は全リソース20分程度で終了していた。 • 運用による更新が積み重なった結果、1年間で1プラットフォーム あたり1万ファイルほどリソースファイルが増加した。その結果、 運用1年あたりでフルビルド1時間までビルド時間が増大した。 • 途中からリリースしたPC版に至ってはビルド時間が2時間を突破 し、開発のイテレーションに支障を来す事態に発展。 リソースのビルド時間の増大
62. 62/84 • 変更が予めわかっていればカテゴリ指定の方がはるかに速いため、 データをカテゴリ分けしてビルドする仕組みを作っていた。 • 運用によりファイルが増え、カテゴリ別でのビルドでさえ時間が かかるようになった。変更がないファイルも毎回ビルドして時間 がかかっていたので変更分だけをビルドしたい。 カテゴリ毎に分割してビルド パラメータデータ キャラクターデータ パラメーターのみ変更したのであれば パラメータカテゴリのみビルドすればよい
63. 63/84 • AssetBundleをビルドするとキャッシュ情報として 「.manifest」というファイルも同時に出力される。 • .manifestファイルは毎回消していたので再利用するように – 作成したAssetBundleの出力パスと同パスに「. manifest」ファイルを配置 – Unityが差分を見てビルドの必要があるかを自動判断して対象ファイルを選別 .manifestキャッシュファイルの再利用 XXXX.unity3d XXXX.unity3d.manifest (このファイルを再利用) ビルドマシンでリソースXXXXをビルド
64. 64/84 • ビルドマシンに消さずに残したまま次回ビルドに利用 – 前回ビルドの影響を大きく受けビルド時間が安定しない可能性があるので却下 • Gitで管理して再利用 – サイズが大きく社内のGitHubEnterpriseサーバーを圧迫するので却下 .manifestファイルの管理問題 ビルドマシンに残す 前のビルド結果に左右される XX.unity3d XX.unity3d.manifest Gitによる差分管理 GHEサーバーを圧迫 XX.unity3d XX.unity3d.manifest
65. 65/84 • 各リリース単位でフォルダ分けしてサーバーにアップロード – リソースビルド後、「.unity3d」と一緒に「.unity3d.manifest」もアップロード – 次回ビルド時に両ファイルをrsyncで全てダウンロード • 全ファイル1.3GBのダウンロードにかかる時間は約3分 – 通信帯域によって時間は増減 リソースサーバーへアップロードして管理 2019/09/04 リリース用リソースフォルダ リソースサーバー 2019/09/06 リリース用リソースフォルダ ビルドマシン アップロード ダウンロード
66. 66/84 • 1時間超のビルドがダウンロード時間を含め30分程度にまで短縮 – 前回のビルド結果からの差分が多いとビルド時間は増加 – 初回ビルドは時間がかかるが既存のリソースをコピーすれば時間は大幅に短縮 – リソースをコピーするだけのジョブも作成 .manifestファイルの管理問題 2019/09/04 リリース用リソースフォルダ リソースサーバー 2019/09/06 不具合修正用リソース (9/6分からコピー) 2019/09/06 リリース用リソースフォルダ ジョブによる リソースフォルダコピー
67. 67/84 リリース安定化のための課題 • リリースするファイルのチェック工数の削減 3プラットフォーム リリースを どう安定させるか
68. 68/84 • 先のスケジュールのデータやテストデータが混入した状態でリ リースしてしまうと、ユーザーへのネタバレリスクが高まったり、 深刻な不具合につながる。リリース直前のファイル差分チェック は安定リリースに必須といえる作業。 • パラメータや画像は一目で未公開データだと判別しやすくネット 上で拡散されてしまうリスクがあるため、先のスケジュールの データが間違って混入していないかは特に重視してチェックする。 リリース直前でのチェック
69. 69/84 • 基本は各リポジトリに対するGitによるdiffを用いたチェックを行 うが、１ヶ月に８回～１０回行われるリリースで更新されるファ イルの合計は3プラットフォームで5000個を超える。 • 月中・月末などのイベント更新は、1回のリリースで1000個以上 のファイルを更新することもある。更新ファイルが非常に多いた め、チェックにかける工数は少しでも削減したい。 • リソースリポジトリ内の画像ファイルに関しては 画像ファイルのみを抽出してdiffを出し確認するように ファイルのチェック工数問題
70. 70/84 • ブランチ同士を比較して差分を出すだけのジョブを作成 • パラメータと画像のみの差分をまとめて出せるように • 毎朝自動でまとめて差分をチェックし、 botで社内SNSに通知 – 毎日どういう差分が出ているか確認 – 自動ビルドのJenkinsfileを応用して1ジョブで全リリースの通知設定が完結 差分確認に集中できるジョブを作成
71. 71/84 • DSL(Domain Specific Language)でのパラメータ検証システム も併用 • 詳細はCEDEC2017の弊社発表資料を参照 • http://tech.cygames.co.jp/archives/3048/ DSLによるパラメータ整合性チェック
72. 72/84 リリース安定化のための課題 • 上流工程での不正なファイル検出・バリデーション強化 3プラットフォーム リリースを どう安定させるか
73. 73/84 • プリコネRではデザイナー・プランナーが自身で作成したデータを Gitでコミットし、プルリクエストを作るところまで対応。開発段 階からGitに触れてもらうことで慣れてもらった。 • 少しでも分からないところや行き詰ったところがあった場合は都 度相談に乗る形で、エンジニアが全力でサポート。 • 各データコミットを各セクションにお願いできたため、エンジニ ア負担は減ったが、不正なデータのコミットも増えた。 他職種によるGit操作
74. 74/84 • ルールは決めているが、どうしてもルールを破ったファイルが コミットされてしまうことがある。 – ファイルエクスプローラー上でコピー＆ペーストしただけで、 Unity上でインポートせずにそのままプルリクエストを投げられてしまう – ファイル名にスペースが入ってしまう • プルリクエストの人力レビューではこれらを検知するのは難しく、 一度プルリクエストを通ってしまうと発見が遅れてしまい、対応 が難しくなってしまうことがある。 不正なmetaデータのコミット
75. 75/84 • 独自のチェックスクリプトを作成し、プルリクエストにひっかけ てmetaファイルをチェック。 • Unityのアセットファイルは一般的なyml形式ファイルで記述され ているため、yml形式ファイルをロードできるスクリプトを用い れば簡単な解析は可能（プリコネRではpythonを使用） metaファイルに対するバリデーションを強化 データ作成 コミット プルリクエスト マージ ビルド デバッグ 本番 不正なファイルはここで食い止めたい
76. 76/84 • metaの存在チェック – コミット忘れ、消し忘れがないか • ファイル名チェック – 空白文字の有無 • metaのguid重複チェック – コピペで作成すると重複する • Materialファイル名とm_Nameプロパティが一致しているか – アセットバンドルのビルド結果が不定になる スクリプトで行っているチェックの詳細
79. 79/84 • 本バリデーションを入れた結果、単純なデータ不整合エラーはほ ぼ撲滅することに成功。 • プルリクエストでのバリデーションはイテレーション速度重視で、 チェックしたい内容を取捨選択。全ての不整合をチェックできる のがベストだが、厚くすると1プルリクエスト当たりのチェック時 間が2時間を越えてしまった。チェック内容を取捨選択してこれを 2分にまで短縮。 バリデーション速度とイテレーション速度
80. 80/84 リリースの安定化 –まとめ– • プリコネRでは１カ月あたり合計5000ファイルを超える更新ファ イルを安定化させるべく、更新ファイルのチェックにかかる時間 やビルドにかかる時間を削減する取り組みをしている。 • 安定化を妨げる不正なデータは上流工程から検出、除去すること でデータ不整合系のエラーは発生させないようにしている。 3プラットフォーム リリースを どう安定させるか
81. まとめ 81/84
82. 82/84 本講演のまとめ • プリコネRでは、互換性を保つアプリ/リソース設計やスケジュー ルの管理を行うことで、アプリ更新時にもメンテナンスフリーな 運用を実現できました。 • CIを用いた大量の開発ブランチの管理コスト改善や、ビルド時間 の削減、バリデーションの強化を行うことで、リリースの安定化 を行いつつ高頻度なリリースにも耐えられる体制を構築しました。
83. 83/84 • メンテナンスフリーに更新できる体制は、ユーザーがいつでもプ レイできる環境を提供するためです。 • 効率化や自動化、リリース前チェックを徹底しているのも、日々 行われるリリース作業を安定化させるためです。リリースが安定 することで運用への信頼度が上がり、結果としてユーザーが常に 安心してプレイできる環境へとつながります。 全てはユーザーの為に
84. 84/84 最後に 開発スタッフは プリコネが大好きです！