プリンセスコネクト！Re:Dive 運用事例

1/84～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～

株式会社Cygames 冨田康之

2/84

概要

• 本講演では、安定したプレイ環境を保ちつつ高頻度リリースを達成するために、プリンセスコネクト！Re:Dive （以後プリコネR）で行った取り組みについて紹介します。

• 新機能やイベント公開時のメンテナンスはユーザーのプレイ体験を著しく阻害します。メンテナンスフリー実現のためには、リソースの下位互換を保つための仕組みと、複数ブランチに跨る大量リソースの管理をサポートする体制が必要です。

• この体制を実現するためのアプリ設計手法、 CIを用いた大量の開発ブランチの管理コスト改善事例について詳細に解説します。

3/84

Tomita Yasuyuki

冨田 康之

技術本部クライアントサイドゲームエンジニア

大手コンシューマーゲーム開発会社を経て、2014年より株式会社Cygamesに所属。クライアントエンジニアとしてネイティブアプリ開発部署に従事。「プリンセスコネクト！Re:Dive」では開発からリリース・運用まで携わりアプリ開発やビルドシステム環境構築を担当している。

自己紹介

4/84

プリコネRの基本情報

• アニメRPGとして2018年2月15日リリース

• iOS / Android / PC の3プラットフォームにて好評配信中

5/84

プリコネRの開発情報

• UnityとGit（GitHubEnterprise）による開発と運用

• バイナリやリソースのビルドやデプロイはJenkinsによるCI

• アプリのアップデートタイミングはおよそ１ヵ月に1～2回

• サーバーやリソースのみのリリースは週に平均２回ほど。月合計でいうと1カ月あたり8回、繁忙期では1か月あたり10回を超える計画リリースが存在

6/84

リリース前から決めていたこと

• 毎週何かしらリリースを行う

• 緊急の不具合修正を除き、通常の機能追加やアプリ更新ではメンテナンスに入らない

ユーザーが安心して遊べるアプリの安定性とユーザーに新たな驚きを提供し続けるための

高頻度リリースとを両立させて提供できる体制が必要

3プラットフォームリリースを

どう安定させるか

大量の開発ブランチをどう管理するか

7/84

この体制を実現するために解決すべき問題

リリース時のアプリ互換性をどう維持するか

8/84

3プラットフォームリリースを

どう安定させるか

大量の開発ブランチをどう管理するか

リリース時のアプリ互換性をどう維持するか

リリース時のアプリ互換性を保つための設計

複数ブランチに跨る大量リソースの管理をサポート

3プラットフォーム向けリリースの安定化

9/84

リリース時のアプリ互換性を保つための設計

複数ブランチに跨る大量リソースの管理をサポート

3プラットフォーム向けリリースの安定化

アジェンダ

10/84

リリース時のアプリ互換性を保つための設計

アジェンダ

11/84

リリース時のアプリ互換性を保つための設計

• プリコネRでは通常の機能追加やアプリ更新ではメンテナンスに入らないということもリリース前から決めていた。

• アプリ更新でメンテナンスに入らないということは、既にリリース済みのアプリバージョンやサーバー処理 / リソースと、互換性を持ちながら新しいアプリバージョンを公開する必要がある。

リリース時のアプリ互換性をどう維持するか

12/84

安定したプレイ環境を保つための基本方針

• 先を見据えて新機能はあらかじめ先入れする

• アプリのバージョン境界にて複数バージョンで動作を保証する

• ストア申請リスクは可能な限り減らす

リリース時のアプリ互換性をどう維持するか

13/84

安定したプレイ環境を保つための基本方針

• 先を見据えて新機能はあらかじめ先入れする

リリース時のアプリ互換性をどう維持するか

14/84

先を見据えて新機能はあらかじめ先入れする

• １回のアプリアップデートでアプリの中に可能な限り次の更新までの機能を入れる（半月～一月分）。

• 1度のメンテナンスで先々の分のDB更新も先行入れ込みすることでメンテ回数を可能な限り減らす。

• 計画メンテナンスを行う際もお知らせした時間内で終わるようにリハーサルを入念に行う。

15/84

安定したプレイ環境を保つための基本方針

• アプリのバージョン境界にて複数バージョンで動作を保証する

リリース時のアプリ互換性をどう維持するか

• アプリはユーザーが任意のタイミングでアップデートするため複数のバージョンが併存する期間が必ず存在する。

• 並存期間中は新アプリは既にリリースされているリソースでも動く必要がある

16/84

機能を先入れする際に立ちはだかる壁

アプリVer 1 公開期間公開済み

リソース更新(併存期間リソース)8/15更新

アプリVer 2 公開期間8/17公開

併存期間 併存期間のリソースは互換性を保つ必要がある

17/84

• 併存期間中に大型の機能解放を行うとサーバー処理やリソースとの下位互換が保てないことがある。

• 併存期間中には大きい機能アップデートは行わないようにし、新機能は強制アップデート後に動き出すようにスケジュールを調整する。

• ストアの浸透が終わる頃を見計らい強制アップデートを仕掛ける。

アプリのバージョン境界問題

18/84

アプリのバージョン境界問題

• リソースデータはアプリのソースコードの影響を受けないデータを開発段階から選別してダウンロードリソース化

アプリVer 1

併存期間リソース

アプリVer 2

併存期間 併存リソースデータ群

◆画像◆パラメータ◆アニメーションデータ◆ムービー◆サウンドetc...

19/84

安定したプレイ環境を保つための基本方針

• ストア申請リスクを可能な限り減らす

リリース時のアプリ互換性をどう維持するか

20/84

• 各プラットフォームのストア申請は、審査が通らずアプリがスケジュール通り出せなかったり、ストアへの反映に時間がかかるケースなどがあるためリスクが大きい。

• リソースをダウンロードするだけで更新できる幅を広げると、ストア申請の回数が減ってリスクもコストも減る。プリコネRでは、ダウンロードリソースとして逃がせるものは逃がすようにしている。

ストア申請のリスク

21/84

UnityのPrefab問題

• PrefabはUnityのソースコードの影響を受けるリソース– [SerializeField]のついたリソース

• アプリ内蔵だとプレハブ修正時にストア申請リスクが発生

22/84

UnityのPrefab問題

• プリコネRではPrefabもダウンロードリソース化

• Prefabのアタッチ外れ、GameObjectのActive ON/OFFがリソース更新で修正できるとメリットとして大きい

• 開発フェーズではアプリに依存しないデータとみなしていた

• アプリバージョンを跨ぐ際に互換性を維持できなくなる問題

23/84

Prefabのダウンロードリソース化(開発)

アプリVer 1

併存期間リソース

アプリVer 2

併存期間 併存リソースデータ群■Prefab【危険】◆画像◆パラメータ◆アニメーションデータ◆ムービーetc...

• 従来のURLとは別にPrefabリソース専用のURLをアプリバー

ジョン毎に用意

24/84

Prefab

アプリ

リソース

Prefabのダウンロードリソース化（運用）

アプリVer 1 アプリVer 2

併存期間リソース用URL

Ver1用Prefab URLhttps://priconne/Ver1/~

Ver2用Prefab URLhttps://priconne/Ver2/~

• イベント前日に見つかったPrefab起因の不具合にも対応でき、ストア申請によるスケジュールの変更リスクの軽減に貢献できた。

25/84

Prefab

アプリ

リソース

Prefabのダウンロードリソース化（運用）

アプリVer 1 アプリVer 2

併存期間リソース用URL

Ver1用Prefab URLhttps://priconne/Ver1/~

Ver2用Prefab URLhttps://priconne/Ver2/~

• 併存用のリソースもアップデート前後で互換性がなくなっていたためアプリごとにURLを分けてダウンロードすることで対応。

26/84

Prefab

アプリ

リソース

Unityアップデート時の対応

Unity2017 Ver Unity2018 Ver

Unity2017 Prefabhttps://priconne/App2017/~

Unity2018用Prefabhttps://priconne/App2018/~

Unity2017用リソースhttps://priconne/Res2017/~

Unity2018用リソースhttps://priconne/Res2018/~

2バージョン運用は管理が大変

27/84

アプリ互換性を保つための設計 –まとめ–

• プリコネRでは、最大限メンテナンスに入らないようにするためのアプリの互換性を考慮した設計、およびスケジュールで運用が行われている。

• アプリバージョン境界で互換性を保つために、ダウンロードするリソースやサーバー処理について特に気を配っている。

リリース時のアプリ互換性をどう維持するか

28/84

複数ブランチに跨る大量リソースの管理をサポート

アジェンダ

• プリコネRではGitによるバージョン管理を用いて開発と運用を進めている。しかし運用開始に伴い、日々の更新でリリースするためのブランチの数と管理コストが爆発的に増えた。

• ブランチ管理コストはゲーム開発にかけられる工数を圧迫し、安定運用を妨げる恐れがあるため、CIジョブによるサポートが必要。

29/84

複数ブランチに跨る大量リソースの管理

大量の開発ブランチをどう管理するか

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

30/84

feature

release

develop

masterhotfix

プリコネRでのGit運用

31/84

• developブランチをメインにしたシンプルな開発フロー

• developからブランチを切りdevelopにプルリクエストを出すという分かりやすい開発フローだったため、特に混乱を生じることもなく開発が進んでいた

feature 進捗レビュー用

develop

新規開発フェーズでのブランチ運用

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/84

• 各スケジュールブランチから各機能ブランチが切られる

• 1～2月先までのスケジュールのブランチが常に存在する

ブランチの数が爆発的に増加

各機能

bugfix

34/84

プリコネRのリリースに関わるリポジトリ

• ファイル同士の依存関係を減らすため細分化した5個のリリース対応リポジトリが存在

リソース サウンドサーバー

ムービーパラメータ

35/84

ブランチの数が爆発的に増加

• １カ月の間、リリース用に用意するブランチ数はおよそ10ブランチ × 5リポジトリ分 = 50ブランチ

• 開発中の依存関係を減らすべくリポジトリを分けたが、管理コストが増大した

リソース サウンド

サーバームービーパラメータ

36/84

ブランチ管理コストの内訳

• 各ブランチの変更を次のブランチへマージする作業の負担増加

• 各ブランチリソースをビルドするためのCIジョブコストの増加

• 各ブランチ内容を確認するための開発環境の管理コストの増加

大量の開発ブランチをどう管理するか

37/84

JenkinsのCIによるブランチ管理コスト改善

• これらブランチ管理コストの増加はJenkinsによるCIを用いて改善を図っていった。

JenkinsCI(継続的インテグレーション)を実現するためのツール

ビルドの自動化 開発コスト削減処理のひとかたまり

をジョブと呼ぶ

38/84

ブランチ管理コストの内訳

• 各ブランチの変更を次のブランチへマージする作業の負担増加

大量の開発ブランチをどう管理するか

39/84

• 「プリコネR」プロジェクト内での通称「ブランチの伝播」

• 前のブランチの変更は次リリースのブランチでも必要になる– 例）2019_05_28の変更は2019_05_29【以降】のブランチへ取り込む必要が

ある

各ブランチの変更を次のブランチへマージ

前のブランチの変更を次のブランチへ取り込む作業

40/84

• 伝播方向を間違えるとブランチが破損する(予定外のリソースが混入したり、Revertで戻しきれなくなる）

• 都度のマージ作業は単純だが、５リポジトリ合計50ブランチを毎回ミスなく伝播するのはとても難しく、失敗するとチーム全体の成果が吹っ飛ぶ

各ブランチの変更を次のブランチへマージ

41/84

• プルリクエスト作成用のCIジョブを作成– GitHubAPI 経由でJekinsからマージ元・先のブランチ名をパラメータを与える– ブランチ命名ルールは統一されているので5リポジトリ分一括で作成可能

ブランチ伝播の簡略化・事故防止

５リポジトリ分のプルリクエストを一気に作成する

プリコネR ブランチルールの例◼masterにマージできるのは「release」か「hotfix」のみ(それ以外はエラー)

◼数字が小さいものから大きいものへのプルリクエストのみ許容

42/84

• ブランチ命名規則から「マージNG」な伝播をシステムで弾く

• ジョブ、プルリクエストhookでルールに沿っているかチェック

ブランチ伝播の簡略化・事故防止

43/84

• このジョブを作成後、ブランチ伝播による事故は撲滅できた。結果、伝播というデリケートな作業を効率的に安心して行えるようになった。

• ルールを破ったブランチ名を作られると事故は防げないが、マージ担当者を決めて勝手にはマージされないようにしている。

• 自動マージ機能は破損ブランチが勝手に伝播されてしまうことを考慮して実装していない。

ブランチ伝播の簡略化・事故防止

44/84

ブランチ管理コストの内訳

• 各ブランチリソースをビルドするためのCIジョブコストの増加

大量の開発ブランチをどう管理するか

45/84

リソースをビルドするためのコスト

• 日々の更新リソースは各プラットフォームで確認するためのリソースビルドが必要。 しかしリソースのビルドには時間がかかる。

１ブランチ当たり１～２時間 × 10ブランチ分 ＝ 最大20時間

• 複数のビルドマシンを用意して並列にビルドさせているが限界はある。そのため、誰もいない夜間に時間のかかるビルドを動かし、朝出社した時点で最新の状況を確認できるようにしておきたい。

46/84

• 10ブランチ存在するので10ジョブ分発生する

• ジョブを増産すると保守コストが後々大変なことになる

自動ジョブの爆発的増加

ブランチ指定などのパラメータがありメンテナンスが困難

※記載のスケジュールは架空のものです

47/84

• 構成を見直し、1つあたりの実行数を可変にするジョブを作成

• パラメータの変更で実行数を変更できるようにする

ジョブ構成の見直し

WindowsiOSAndroid

3プラットフォームビルド(量産しない)

3プラットフォームビルドジョブ(このジョブが量産されていた)

WindowsiOSAndroid

ジョブ実行数 可変ジョブ

AfterBefore

48/84

• Jenkinsの各ジョブはJenkinsfileというGroovyスクリプトで詳細に処理を組み立てることができる

• 独自のセパレータ[-- ] （ハイフン二つ）を決めJenkinsfile内の処理でJenkinsに指定するパラメータを分割

• 分割した各パラメータを下流のジョブに流す

Jenkinsfileを用いてパラメータを工夫

49/84

Jenkinsfileによるパラメータ分割の記述例

50/84

• とても簡単なスクリプトだが効果は絶大。自動ジョブ系は1つだけメンテナンスすればよく、ジョブ数増加による保守コストが激減。

• パラメータ変更だけで良いのでエンジニア以外の職種も自動ジョブが整備できるようになった。

• ビルド実行数を増やせるこの仕組みは、その他のジョブにも応用しやすくジョブ数の削減に貢献できた。

自動ビルドをより設定しやすく改良

51/84

ブランチ管理コストの内訳

• 各ブランチ内容を確認するための開発環境の管理コストの増加

大量の開発ブランチをどう管理するか

52/84

• プリコネRに存在する開発環境は40以上。各ブランチの内容を確認するには適切な環境への接続が必要になる。

• どの環境に接続すれば各ブランチの作業内容が確認できるか、デバッガやプランナーからは分かりづらく、混乱が発生した。

• ホワイトボードやWiki管理していたが更新が頻繁でなく最新情報に保つのが難しい。各環境の状況は、可能な限り自動的に集められるようにしたい。

開発確認環境の増加

53/84

• 各開発環境へはブランチ名とデプロイ先のパラメータをJenkins実行時に指定する。この情報を流用したい。

• デプロイはJenkinsが必須なため情報がジョブ内に集約されている

サーバーへのデプロイジョブの情報を利用

2019/09/04リリース向け対応

開発サーバー

2019/09/06リリース向け対応

デプロイパラメータ・ブランチ名・デプロイ先

デプロイ

デプロイ

54/84

• 開発者が必ず行うデプロイ作業のパラメータを保存しておく

• 保存しておいたパラメータを収集して常に最新の情報を自動表示

デプロイ情報を利用してWebページ作成

・ブランチ名・デプロイ先

Jenkinsの情報を収集して表示

55/84

• このWebページを作ることでプランナーやデバッガの混乱はなくなった。

• 開発者の行動にフックしているため自動更新、保守も不要。

デプロイ情報を利用してWebページ作成

・ブランチ名・デプロイ先

Jenkinsの情報を収集して表示

56/84

複数ブランチ管理をサポート –まとめ–

• プリコネRでは運用の結果、ブランチ数、及び管理コストが爆発的に増えた。

• 主にブランチのマージコスト、ビルドコスト、各ブランチ開発環境の管理コストが増えていたため、JenkinsのCIジョブを調整することで開発をサポートし、高頻度なリリースにも耐えられる体制づくりに貢献。

大量の開発ブランチをどう管理するか

57/84

3プラットフォーム向けリリースの安定化

アジェンダ

58/84

3プラットフォーム向けリリースの安定化

• プリコネRはiOS / Android / PC の3プラットフォームで運用されているが、１カ月で更新するファイル数は合計5000ファイルを超える。この数になると、正しいファイルかのチェックにも時間がかかり高頻度リリースの妨げになるため効率化を図る必要がある。

• ビルドにかかる時間や不具合特定にかかる時間などは、本来のゲーム開発にかけられる工数を圧迫し、運用の安定化を妨げる恐れがあるため時間削減をしたい。

3プラットフォームリリースを

どう安定させるか

59/84

リリース安定化のための課題

• リソースビルド時間の削減

• リリースするファイルのチェック工数の削減

• 上流工程での不正なファイル検出・バリデーション強化

3プラットフォームリリースを

どう安定させるか

60/84

リリース安定化のための課題

• リソースビルド時間の削減

3プラットフォームリリースを

どう安定させるか

61/84

• 日々の更新リソースは各プラットフォームで確認するためのビルドが必要。リリース当初は全リソース20分程度で終了していた。

• 運用による更新が積み重なった結果、1年間で1プラットフォームあたり1万ファイルほどリソースファイルが増加した。その結果、運用1年あたりでフルビルド1時間までビルド時間が増大した。

• 途中からリリースしたPC版に至ってはビルド時間が2時間を突破し、開発のイテレーションに支障を来す事態に発展。

リソースのビルド時間の増大

62/84

• 変更が予めわかっていればカテゴリ指定の方がはるかに速いため、データをカテゴリ分けしてビルドする仕組みを作っていた。

• 運用によりファイルが増え、カテゴリ別でのビルドでさえ時間がかかるようになった。変更がないファイルも毎回ビルドして時間がかかっていたので変更分だけをビルドしたい。

カテゴリ毎に分割してビルド

パラメータデータ

キャラクターデータ

パラメーターのみ変更したのであればパラメータカテゴリのみビルドすればよい

63/84

• AssetBundleをビルドするとキャッシュ情報として「.manifest」というファイルも同時に出力される。

• .manifestファイルは毎回消していたので再利用するように– 作成したAssetBundleの出力パスと同パスに「. manifest」ファイルを配置– Unityが差分を見てビルドの必要があるかを自動判断して対象ファイルを選別

.manifestキャッシュファイルの再利用

XXXX.unity3dXXXX.unity3d.manifest(このファイルを再利用)

ビルドマシンでリソースXXXXをビルド

64/84

• ビルドマシンに消さずに残したまま次回ビルドに利用– 前回ビルドの影響を大きく受けビルド時間が安定しない可能性があるので却下

• Gitで管理して再利用– サイズが大きく社内のGitHubEnterpriseサーバーを圧迫するので却下

.manifestファイルの管理問題

ビルドマシンに残す前のビルド結果に左右される

XX.unity3d

XX.unity3d.manifest

Gitによる差分管理GHEサーバーを圧迫

XX.unity3d

XX.unity3d.manifest

65/84

• 各リリース単位でフォルダ分けしてサーバーにアップロード– リソースビルド後、「.unity3d」と一緒に「.unity3d.manifest」もアップロード– 次回ビルド時に両ファイルをrsyncで全てダウンロード

• 全ファイル1.3GBのダウンロードにかかる時間は約3分– 通信帯域によって時間は増減

リソースサーバーへアップロードして管理

2019/09/04リリース用リソースフォルダ

リソースサーバー

2019/09/06リリース用リソースフォルダ

ビルドマシン

アップロード

ダウンロード

66/84

• 1時間超のビルドがダウンロード時間を含め30分程度にまで短縮– 前回のビルド結果からの差分が多いとビルド時間は増加– 初回ビルドは時間がかかるが既存のリソースをコピーすれば時間は大幅に短縮– リソースをコピーするだけのジョブも作成

.manifestファイルの管理問題

2019/09/04リリース用リソースフォルダ

リソースサーバー 2019/09/06不具合修正用リソース

(9/6分からコピー)

2019/09/06リリース用リソースフォルダ

ジョブによるリソースフォルダコピー

67/84

リリース安定化のための課題

• リリースするファイルのチェック工数の削減

3プラットフォームリリースを

どう安定させるか

68/84

• 先のスケジュールのデータやテストデータが混入した状態でリリースしてしまうと、ユーザーへのネタバレリスクが高まったり、深刻な不具合につながる。リリース直前のファイル差分チェックは安定リリースに必須といえる作業。

• パラメータや画像は一目で未公開データだと判別しやすくネット上で拡散されてしまうリスクがあるため、先のスケジュールのデータが間違って混入していないかは特に重視してチェックする。

リリース直前でのチェック

69/84

• 基本は各リポジトリに対するGitによるdiffを用いたチェックを行うが、１ヶ月に８回～１０回行われるリリースで更新されるファイルの合計は3プラットフォームで5000個を超える。

• 月中・月末などのイベント更新は、1回のリリースで1000個以上のファイルを更新することもある。更新ファイルが非常に多いため、チェックにかける工数は少しでも削減したい。

• リソースリポジトリ内の画像ファイルに関しては画像ファイルのみを抽出してdiffを出し確認するように

ファイルのチェック工数問題

70/84

• ブランチ同士を比較して差分を出すだけのジョブを作成

• パラメータと画像のみの差分をまとめて出せるように

• 毎朝自動でまとめて差分をチェックし、 botで社内SNSに通知– 毎日どういう差分が出ているか確認– 自動ビルドのJenkinsfileを応用して1ジョブで全リリースの通知設定が完結

差分確認に集中できるジョブを作成

71/84

• DSL(Domain Specific Language)でのパラメータ検証システムも併用

• 詳細はCEDEC2017の弊社発表資料を参照

• http://tech.cygames.co.jp/archives/3048/

DSLによるパラメータ整合性チェック

72/84

リリース安定化のための課題

• 上流工程での不正なファイル検出・バリデーション強化

3プラットフォームリリースを

どう安定させるか

73/84

• プリコネRではデザイナー・プランナーが自身で作成したデータをGitでコミットし、プルリクエストを作るところまで対応。開発段階からGitに触れてもらうことで慣れてもらった。

• 少しでも分からないところや行き詰ったところがあった場合は都度相談に乗る形で、エンジニアが全力でサポート。

• 各データコミットを各セクションにお願いできたため、エンジニア負担は減ったが、不正なデータのコミットも増えた。

他職種によるGit操作

74/84

• ルールは決めているが、どうしてもルールを破ったファイルがコミットされてしまうことがある。– ファイルエクスプローラー上でコピー＆ペーストしただけで、

Unity上でインポートせずにそのままプルリクエストを投げられてしまう– ファイル名にスペースが入ってしまう

• プルリクエストの人力レビューではこれらを検知するのは難しく、一度プルリクエストを通ってしまうと発見が遅れてしまい、対応が難しくなってしまうことがある。

不正なmetaデータのコミット

75/84

• 独自のチェックスクリプトを作成し、プルリクエストにひっかけてmetaファイルをチェック。

• Unityのアセットファイルは一般的なyml形式ファイルで記述されているため、yml形式ファイルをロードできるスクリプトを用いれば簡単な解析は可能（プリコネRではpythonを使用）

metaファイルに対するバリデーションを強化

データ作成

コミットプルリクエスト マージ ビルド デバッグ 本番

不正なファイルはここで食い止めたい

76/84

• metaの存在チェック– コミット忘れ、消し忘れがないか

• ファイル名チェック– 空白文字の有無

• metaのguid重複チェック– コピペで作成すると重複する

• Materialファイル名とm_Nameプロパティが一致しているか– アセットバンドルのビルド結果が不定になる

スクリプトで行っているチェックの詳細

79/84

• 本バリデーションを入れた結果、単純なデータ不整合エラーはほぼ撲滅することに成功。

• プルリクエストでのバリデーションはイテレーション速度重視で、チェックしたい内容を取捨選択。全ての不整合をチェックできるのがベストだが、厚くすると1プルリクエスト当たりのチェック時間が2時間を越えてしまった。チェック内容を取捨選択してこれを2分にまで短縮。

バリデーション速度とイテレーション速度

80/84

リリースの安定化 –まとめ–

• プリコネRでは１カ月あたり合計5000ファイルを超える更新ファイルを安定化させるべく、更新ファイルのチェックにかかる時間やビルドにかかる時間を削減する取り組みをしている。

• 安定化を妨げる不正なデータは上流工程から検出、除去することでデータ不整合系のエラーは発生させないようにしている。

3プラットフォームリリースを

どう安定させるか

まとめ

81/84

82/84

本講演のまとめ

• プリコネRでは、互換性を保つアプリ/リソース設計やスケジュールの管理を行うことで、アプリ更新時にもメンテナンスフリーな運用を実現できました。

• CIを用いた大量の開発ブランチの管理コスト改善や、ビルド時間の削減、バリデーションの強化を行うことで、リリースの安定化を行いつつ高頻度なリリースにも耐えられる体制を構築しました。

83/84

• メンテナンスフリーに更新できる体制は、ユーザーがいつでもプレイできる環境を提供するためです。

• 効率化や自動化、リリース前チェックを徹底しているのも、日々行われるリリース作業を安定化させるためです。リリースが安定することで運用への信頼度が上がり、結果としてユーザーが常に安心してプレイできる環境へとつながります。

全てはユーザーの為に

84/84

最後に

開発スタッフはプリコネが大好きです！