CEDEC2019感想 プリコネに学ぶCIツールの偉大さと難しさ

ゲーム開発

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

概要

はじめに：プリコネは基本的にメンテナンスフリー運営

  • 先を見据えて新機能はあらかじめ先入れする（半月〜一月分）
  • アプリのバージョン境界にて複数バージョンで動作を保証する
  • リジェクトされる可能性のあるストア申請リスクを減らす
    • アプリでなく、ダウンロードリソースに逃す


問題1. 新バージョンリリース時のアプリ互換性

  • リリース時は旧バージョンと新バージョンの互換性を約束する
    • DLデータも旧バージョン用と新バージョン用をそれぞれ用意
  • 新機能は出来るだけ予め投入


問題2. 膨れ上がる開発ブランチの管理

  • ビルドやデプロイはCIツールのJenkinsに行わせる
    • 全てを直列にビルドしていると膨大な時間が
      • 並列にビルドさせようとしたら今度はJenkinsのジョブ数が膨大になった
      • ジョブの引数で分岐させるよう対応
    • プログラムとリソースのリポジトリを分け、作業の見える化を進めて効率化した
      • さらにブランチ数が増え、管理・チェック・マージコストが増大した
        • ブランチの命名規則を統一することで、マージ作業もJenkinsに任せるようになった
          • リリース予定日時など
      • チェック作業効率化のため、日時とプラットフォームがあれば誰でも環境を取得できるようにした


問題3. 3プラットフォームのリリースをどう安定させるか

  • ビルド時間削減のため、差分があったファイルのみをビルドできるよう中間ファイルを用意
  • プログラマー以外の職種もgitを使ってコミットする
    • 不正なデータがコミットされないようプルリク時にスクリプトで整合性チェック


感想

簡単にJenkinsで、というが、開発でのJenkins運用は苦難の道のり。さすがサイゲ。

Jenkinsは基本的に以下のような要素をトリガーとして特定のスクリプトを実行します。

  • 定時 / 一定期間
  • バージョン管理ツールをフックしてコミットやマージを感知した時
  • 手動

Jenkinsによるシステム構築中は、あてにするファイルが存在しない・命名規則が間違っている・他のジョブが実行中だったなどなど、失敗が多発したと思います。

例外処理やファイルの退避、他のジョブ待ちによるデッドロック回避など、数多くの工夫を凝らさないとここまでの体勢は整えられないはずです。

開発の初期段階から運営スタイルを見越して先の問題を潰していける姿勢と、その技術力にお見それしました。

（本当に問題、起きてないの？）

多くの人間がバージョン管理ツールを使うと、必ずミスが発生します。人為ミスは0にはできません。

プルリク時にデータチェックと言ってましたが、それにも限界があるはずです。

月1という高頻度のリリース頻度に加え3プラットフォーム提供、さらに旧バージョンとの互換性維持となると、少なからずチェック漏れも発生しそうです。

プリコネやってないので大きいことは言えませんが、バグの頻度が気になります。

問題が起きていないとすると、一体どれだけの人が動いているのだろうか。。。

最後に

僕や周りのメンバーを監視して、それ自動化できるからやっとくよ　って言ってくれる人が欲しい。

きっと探せばいっぱいある。これからのゲーム開発はこれまで以上に少数精鋭になって、機械に仕事をさせる時代になるだろう。