9月4日～6日の期間、CEDEC 2019が、パシフィコ横浜で開催された。最終日にあたる26日、Cygamesによる講演「プリンセスコネクト！Re:Dive運用事例 ～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～」が行われた。
本講演では、Cygamesの技術本部クライアントサイドに所属するゲームエンジニアである冨田康之氏が登壇し、iPhone、Android、PCの3種のプラットフォームでリリースされている『プリンセスコネクト！Re:Dive』における、高頻度化するリリース作業を安定させるための手法を紹介している。
![]()
▲登壇した冨田康之氏。
『プリンセスコネクト！Re:Dive』（以下、『プリコネR』）は、現在3種のプラットフォームで同時に運営をしており、開発環境には当然違いが出てくる。しかし、同時に運営していくにあたっては、アプリの互換性を常々考慮しなくてはいけない。
『プリコネR』では、Gitによるバージョン管理を開発、運用に利用している。しかし、運用後に発生した大きな問題として、ブランチの数の増大と、それに伴う管理コスト上昇をあげている。
こうしたブランチ管理コストにリソースを割けば、当然ゲーム開発の工数も圧迫してしまう。開発ブランチをいかに管理するかが、高頻度のリリースを進めていくにあたっては重要となる。
![]()
![]()
『プリコネR』のGit運用の方法を図式化したものが以下のスライドだ。ここでは、スライドにも書かれているように「Git-Flow」をベースにした開発手法が紹介されている。
![]()
新規開発フェーズでは、当然開発起点となるdevelopブランチからスタートする。この段階においては、developから派生するプルリクエストを出すだけのわかりやすい形になっている。
![]()
これをリリース直前にGit-Flowに準じた形に移行する。この写真においては、リリースする日付をブランチ名にしているが、これは実際の開発現場で使っていたものとは異なる。
![]()
そして、実際にリリースするとなると、システムの改修やイベントの開始など、様々なスケジュールに合わせたブランチが追加されていくと、そこからさらに各機能に合わせたブランチも必要になり、細々としたバグフィックスまで発生してしまう。
![]()
さらに、このブランチの問題に拍車をかけたのがリポジトリの存在だった。『プリコネR』では、ファイル同士の依存関係を減らすというも目的のために、リポジトリを5個に分けている。
![]()
こうなると、それぞれが分割されているために、ひとつひとつのリポジトリに先ほどのブランチが用意され、単純に5倍のブランチが生まれることになる。
![]()
こうした状況の改善策として、JenkinsでCI（継続的インテグレーション）を用いるというものだ。ビルドを自動化することにより、消費するリソースを低減し、開発コストの削減にもつながる。
![]()
ここからは、具体的なブランチ管理コストの内訳について、冨田氏がまとめた内容となる。まずは、各ブランチに変更があった際、それを次のブランチにマージする作業があまりにも多大であったと富田氏は語っている。
![]()
![]()
さらに、マージする方向を間違えたりした場合、ブランチの破損が発生し、これは簡単には取り戻せない。マージ作業自体は単純であっても、数が多くなればミスはどうしても発生する。そのひとつのミスで全体の成果が無駄になってしまう可能性もあるため、このマージによる手間や危険は極力減らしたい。
そのため、富田氏はブランチの命名規則を利用することで、マージ不可能なブランチを作る環境を構築し、マージによる事故を減らしていった。
![]()
![]()
次に、リソースをビルドするためのコストという話題に移る。日々の更新リソースは、当然各プラットフォームごとに必要になる。リソースのビルドにも必然的に時間がかかる。夜間にビルドを動かすことで、翌日の朝に確認できるような環境が望ましいと富田氏は考えている。
![]()
ブランチの数だけ処理すべきジョブが増えていくので、ブランチの肥大に伴って、ジョブの数も増大していく。こうした増産体制になってしまうと、これらの保守にコストがかかってしまい、メンテナンスにも影響を及ぼしてくる。
そこで富田氏は、これらのジョブの構成を見直し、毎回プラットフォームごとに量産していたジョブを、ひとつのビルドとして量産の必要のない体制を作っている。ジョブを可変にするこで、それをビルドにあてはめていくという形になった。
![]()
![]()
jenkinsのジョブであれば、Jenkinsfileを用いることで詳細な処理を事前に組み立てられる。詳細な方法もスライドで振れている。
![]()
![]()
そして、何よりも効果が絶大なのは、自動ビルドの改良という手法だ。自動ジョブはメンテナンスの手間が大きく省けるため、保守コストが確実に減少する。エンジニア以外の職種でも自動ジョブの整備はできるという点も大きく貢献している。
![]()
3つ目の問題点として、開発環境の増加によって確認作業が難しくなってしまったことを挙げている。特に、デバッガーやプランナーが作業内容を確認しようとしたとき、確認したいブランチにはどの環境から接続できるのかがわかりづらいことが致命的となった。
![]()
これに対しては、デプロイジョブを利用し、ブランチ名とデプロイ先のパラメータ、この2点をJenkins実行時に指定する点を応用し、以下のスライドのような形でまとめている。
![]()
![]()
![]()
▲ブランチ管理に関するまとめ。
ここからは、3つのプラットフォームに向けてのリリースを安定化させるため、いかに効率化を図るかという点に焦点を当てた話となる。
![]()
日々の更新リソースについては、さきほどのブランチの話でも少しあがったが、各プラットフォームで確認するためのビルドが必要だったため、リソースファイルが爆発的に増加していった。最初は全リソースでも20分程度で済んでいた作業が、1時間もかかるようになってしまったという。
当初は、データをカテゴリ分けしていたが、運用が進むにつれてファイル数が増加していき、カテゴリ別に分けたとしてもビルドに途方もない時間がかかるようになっていた。そこで、変更分だけをビルドしたいという要望もあがってきた。
![]()
![]()
manifestファイルの管理についても富田氏は考慮し、ビルドマシンにファイルを残しておいたり、Gitで管理しながら再利用するなどを考案してみたが、それぞれに発生する問題点を見逃せないため却下している。
![]()
次に、リリース単位でフォルダを分けてサーバーにアップロードするという管理方法に変えたところ、1時間を超えていたビルドを、ダウンロードにかかる時間を含めたうえで、半分程度まで短縮することに成功している。
![]()
![]()
▲当然、前回ビルドからの差分が多ければ多いほどビルド時間は増加することになる。それでも工数は確実に減る。リソースをコピーするジョブも用意しておけば、環境は大きく改善される。
実際にリリースが差し迫った段階でのチェック要項として、さらに先のリリースで使うテストデータなどが混入してしまうと、ネタバレや不具合などの申告なトラブルの元となる。そのため、安定したリリースのためには、直前の差分チェックが必要不可欠となる。
![]()
![]()
▲現在は、差分確認に集中するジョブを作成し、毎朝差分をお知らせするbotを社内SNSで共有することで、日々の差分の発生を把握しているそうだ。
![]()
▲パラメータ検証に関しては「Domain Specific Language」を併用している。こちらについては、2017年のCEDEC 2017で公開された資料を参考にしてほしい。なお、こちらの講演「ユーザーを飽きさせない高頻度の更新を可能にする開発運用ノウハウ～ハイスピードな開発、リリースを実現するために～」はSocial Game Infoでもレポートを掲載している。
●Cygames Engineers' Blog「CEDEC 2017 フォローアップ」
http://tech.cygames.co.jp/archives/3048/
●関連記事
【CEDEC2017】“最高のコンテンツ作り”のための開発運用を支えるCygames独自のDSL その仕組みとノウハウが明かされる
さらにリリース安定化の課題としては、上流工程での不正ファイル検出とバリデーションの強化にも着目すべきだと富田氏は述べている。『プリコネR』の開発現場では、デザイナーやプランナーもGitに増えており、そのおかげでエンジニアの負担が減ったものの、不正なデータのコミットも増えてしまった。
ルールは定められているのものの、そのルールにそぐわないファイルがコミットされるのを完全には防げない。そして、それを人力で検知するのは難しいため、一度プルリクエストが通ってしまった時点で対応は難しい。
![]()
![]()
であれば、プルリクエストの時点で不正ファイルを食い止められる環境を構築すべきだ。そのためには、チェックスクリプトを用意しておき、簡単な解析をできるよう、事前に準備をしておく必要がある。
![]()
![]()
▲チェック項目の詳細な内容についての例も紹介している。もちろん、必要に応じてチェック項目は増減する。
![]()
![]()
▲プログラムの一例。
こうしたバリデーションの導入により、データ不整合によるエラーの撲滅に成功。プルリクエスト時点でのバリデーションについては、チェック内容を取捨選択することにより、チェック時間が長くならないように考慮している。
![]()
![]()
▲リリース安定化についてのまとめ。
公演全体のまとめとして、3種のプラットフォームで展開する「プリコネR」では、互換性を保つための設計や、スケジュール管理に力を入れることで、アプリ更新時にメンテナンスフリーな環境を作ったこと。
CIを使用した開発ブラン管理の改善や、ビルド時間の削減。そしてバリデーションの見直しによって、高頻度なリリースに対応できる体制を構築しているとした。
![]()
こうしたメンテナンスフリーな環境作りは、ユーザーがいつでもゲームをプレイできる環境を作るためであり、ユーザーファーストにつながっている。リリース作業の安定は運用への信頼度を向上させ、ユーザーが安心してゲームをプレイできる環境ができあがっていくことを主張しながら、富田氏による講演は終了した。
![]()
© Cygames, Inc.
本講演では、Cygamesの技術本部クライアントサイドに所属するゲームエンジニアである冨田康之氏が登壇し、iPhone、Android、PCの3種のプラットフォームでリリースされている『プリンセスコネクト！Re:Dive』における、高頻度化するリリース作業を安定させるための手法を紹介している。
▲登壇した冨田康之氏。
『プリンセスコネクト！Re:Dive』（以下、『プリコネR』）は、現在3種のプラットフォームで同時に運営をしており、開発環境には当然違いが出てくる。しかし、同時に運営していくにあたっては、アプリの互換性を常々考慮しなくてはいけない。
『プリコネR』では、Gitによるバージョン管理を開発、運用に利用している。しかし、運用後に発生した大きな問題として、ブランチの数の増大と、それに伴う管理コスト上昇をあげている。
こうしたブランチ管理コストにリソースを割けば、当然ゲーム開発の工数も圧迫してしまう。開発ブランチをいかに管理するかが、高頻度のリリースを進めていくにあたっては重要となる。
『プリコネR』のGit運用の方法を図式化したものが以下のスライドだ。ここでは、スライドにも書かれているように「Git-Flow」をベースにした開発手法が紹介されている。
新規開発フェーズでは、当然開発起点となるdevelopブランチからスタートする。この段階においては、developから派生するプルリクエストを出すだけのわかりやすい形になっている。
これをリリース直前にGit-Flowに準じた形に移行する。この写真においては、リリースする日付をブランチ名にしているが、これは実際の開発現場で使っていたものとは異なる。
そして、実際にリリースするとなると、システムの改修やイベントの開始など、様々なスケジュールに合わせたブランチが追加されていくと、そこからさらに各機能に合わせたブランチも必要になり、細々としたバグフィックスまで発生してしまう。
さらに、このブランチの問題に拍車をかけたのがリポジトリの存在だった。『プリコネR』では、ファイル同士の依存関係を減らすというも目的のために、リポジトリを5個に分けている。
こうなると、それぞれが分割されているために、ひとつひとつのリポジトリに先ほどのブランチが用意され、単純に5倍のブランチが生まれることになる。
こうした状況の改善策として、JenkinsでCI（継続的インテグレーション）を用いるというものだ。ビルドを自動化することにより、消費するリソースを低減し、開発コストの削減にもつながる。
ここからは、具体的なブランチ管理コストの内訳について、冨田氏がまとめた内容となる。まずは、各ブランチに変更があった際、それを次のブランチにマージする作業があまりにも多大であったと富田氏は語っている。
さらに、マージする方向を間違えたりした場合、ブランチの破損が発生し、これは簡単には取り戻せない。マージ作業自体は単純であっても、数が多くなればミスはどうしても発生する。そのひとつのミスで全体の成果が無駄になってしまう可能性もあるため、このマージによる手間や危険は極力減らしたい。
そのため、富田氏はブランチの命名規則を利用することで、マージ不可能なブランチを作る環境を構築し、マージによる事故を減らしていった。
次に、リソースをビルドするためのコストという話題に移る。日々の更新リソースは、当然各プラットフォームごとに必要になる。リソースのビルドにも必然的に時間がかかる。夜間にビルドを動かすことで、翌日の朝に確認できるような環境が望ましいと富田氏は考えている。
ブランチの数だけ処理すべきジョブが増えていくので、ブランチの肥大に伴って、ジョブの数も増大していく。こうした増産体制になってしまうと、これらの保守にコストがかかってしまい、メンテナンスにも影響を及ぼしてくる。
そこで富田氏は、これらのジョブの構成を見直し、毎回プラットフォームごとに量産していたジョブを、ひとつのビルドとして量産の必要のない体制を作っている。ジョブを可変にするこで、それをビルドにあてはめていくという形になった。
jenkinsのジョブであれば、Jenkinsfileを用いることで詳細な処理を事前に組み立てられる。詳細な方法もスライドで振れている。
そして、何よりも効果が絶大なのは、自動ビルドの改良という手法だ。自動ジョブはメンテナンスの手間が大きく省けるため、保守コストが確実に減少する。エンジニア以外の職種でも自動ジョブの整備はできるという点も大きく貢献している。
3つ目の問題点として、開発環境の増加によって確認作業が難しくなってしまったことを挙げている。特に、デバッガーやプランナーが作業内容を確認しようとしたとき、確認したいブランチにはどの環境から接続できるのかがわかりづらいことが致命的となった。
これに対しては、デプロイジョブを利用し、ブランチ名とデプロイ先のパラメータ、この2点をJenkins実行時に指定する点を応用し、以下のスライドのような形でまとめている。
▲ブランチ管理に関するまとめ。
ここからは、3つのプラットフォームに向けてのリリースを安定化させるため、いかに効率化を図るかという点に焦点を当てた話となる。
日々の更新リソースについては、さきほどのブランチの話でも少しあがったが、各プラットフォームで確認するためのビルドが必要だったため、リソースファイルが爆発的に増加していった。最初は全リソースでも20分程度で済んでいた作業が、1時間もかかるようになってしまったという。
当初は、データをカテゴリ分けしていたが、運用が進むにつれてファイル数が増加していき、カテゴリ別に分けたとしてもビルドに途方もない時間がかかるようになっていた。そこで、変更分だけをビルドしたいという要望もあがってきた。
manifestファイルの管理についても富田氏は考慮し、ビルドマシンにファイルを残しておいたり、Gitで管理しながら再利用するなどを考案してみたが、それぞれに発生する問題点を見逃せないため却下している。
次に、リリース単位でフォルダを分けてサーバーにアップロードするという管理方法に変えたところ、1時間を超えていたビルドを、ダウンロードにかかる時間を含めたうえで、半分程度まで短縮することに成功している。
▲当然、前回ビルドからの差分が多ければ多いほどビルド時間は増加することになる。それでも工数は確実に減る。リソースをコピーするジョブも用意しておけば、環境は大きく改善される。
実際にリリースが差し迫った段階でのチェック要項として、さらに先のリリースで使うテストデータなどが混入してしまうと、ネタバレや不具合などの申告なトラブルの元となる。そのため、安定したリリースのためには、直前の差分チェックが必要不可欠となる。
▲現在は、差分確認に集中するジョブを作成し、毎朝差分をお知らせするbotを社内SNSで共有することで、日々の差分の発生を把握しているそうだ。
▲パラメータ検証に関しては「Domain Specific Language」を併用している。こちらについては、2017年のCEDEC 2017で公開された資料を参考にしてほしい。なお、こちらの講演「ユーザーを飽きさせない高頻度の更新を可能にする開発運用ノウハウ～ハイスピードな開発、リリースを実現するために～」はSocial Game Infoでもレポートを掲載している。
●Cygames Engineers' Blog「CEDEC 2017 フォローアップ」
http://tech.cygames.co.jp/archives/3048/
●関連記事
【CEDEC2017】“最高のコンテンツ作り”のための開発運用を支えるCygames独自のDSL その仕組みとノウハウが明かされる
さらにリリース安定化の課題としては、上流工程での不正ファイル検出とバリデーションの強化にも着目すべきだと富田氏は述べている。『プリコネR』の開発現場では、デザイナーやプランナーもGitに増えており、そのおかげでエンジニアの負担が減ったものの、不正なデータのコミットも増えてしまった。
ルールは定められているのものの、そのルールにそぐわないファイルがコミットされるのを完全には防げない。そして、それを人力で検知するのは難しいため、一度プルリクエストが通ってしまった時点で対応は難しい。
であれば、プルリクエストの時点で不正ファイルを食い止められる環境を構築すべきだ。そのためには、チェックスクリプトを用意しておき、簡単な解析をできるよう、事前に準備をしておく必要がある。
▲チェック項目の詳細な内容についての例も紹介している。もちろん、必要に応じてチェック項目は増減する。
▲プログラムの一例。
こうしたバリデーションの導入により、データ不整合によるエラーの撲滅に成功。プルリクエスト時点でのバリデーションについては、チェック内容を取捨選択することにより、チェック時間が長くならないように考慮している。
▲リリース安定化についてのまとめ。
公演全体のまとめとして、3種のプラットフォームで展開する「プリコネR」では、互換性を保つための設計や、スケジュール管理に力を入れることで、アプリ更新時にメンテナンスフリーな環境を作ったこと。
CIを使用した開発ブラン管理の改善や、ビルド時間の削減。そしてバリデーションの見直しによって、高頻度なリリースに対応できる体制を構築しているとした。
こうしたメンテナンスフリーな環境作りは、ユーザーがいつでもゲームをプレイできる環境を作るためであり、ユーザーファーストにつながっている。リリース作業の安定は運用への信頼度を向上させ、ユーザーが安心してゲームをプレイできる環境ができあがっていくことを主張しながら、富田氏による講演は終了した。
（取材・文 ライター：宮居春馬）
■『プリンセスコネクト！Re:Dive』
© Cygames, Inc.
