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

Slide 1

Slide 1 text

プリンセスコネクト！Re:Dive 運用事例 1/84 ～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～株式会社Cygames 冨田康之

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

まとめ 81/84

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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