運用中の大規模オンラインゲームで8年ぶりにPHPバージョンアップをした話

2 2012年 KLab株式会社に入社  2016年からBLEACH Brave Soulsにサーバサイドエンジニアとして参画。  2021年からサーバチームのリーダーをしています。    前職は、金融システムや物流管理のシステムを作っていました。 
  福田陽介  エンジニア  KLabGames事業本部  KLab株式会社  画像 

3 今日話すこと  • 前提説明（ゲームの説明・バージョンアップの理由）  • 開発方針（修正箇所洗い出し・ブランチについて）  • 後回しにしたこと  • 運用中プロジェクトでPHP8.1切り替えをどう進行したか 
• バージョン移行後に起こったトラブル  • 数値で見る実績と効果  • まとめ 

4 前提説明 

5 BLEACH Brave Soulsとは  『BLEACH』を題材とした3Dアクションゲームです。   登場する人気キャラクターを操作し、  本格的で爽快なアクションを楽しむ事ができます。   

6 サービスの特徴  • 2015-07-23にリリースされ、8周年を迎えた  • リクエスト数：1000 - 7000 rps  •
アップデート周期：1〜2ヶ月に1度、機能追加を実施  • ゲームサーバ、運用ツール、バッチがPHPで実装されている  BLEACH Brave Soulsとは 

7 • バージョンアップ前のPHPバージョンは  ◦ 5.5.13  ▪ 2014-01-26 リリース  ▪ EOLは
2016-07-10  なぜPHPバージョンアップをしたかったか？ 

8 • PHPのセキュリティサポート懸念  なぜPHPバージョンアップをしたかったか？ 

9 • PHPのセキュリティサポート懸念  • 導入しようとしたライブラリでPHP7.x以上が条件    なぜPHPバージョンアップをしたかったか？ 

10 • PHPのセキュリティサポート懸念  • 導入しようとしたライブラリでPHP7.x以上が条件  • 運用ツールのレスポンスタイムが遅い  なぜPHPバージョンアップをしたかったか？ 

11 • PHPのセキュリティサポート懸念  • 導入しようとしたライブラリでPHP7.x以上が条件  • 運用ツールのレスポンスタイムが遅い  • PHPの新しい機能や記法を使いたい  なぜPHPバージョンアップをしたかったか？ 

12 • PHPのセキュリティサポート懸念  • 導入しようとしたライブラリでPHP7.x以上が条件  • 運用ツールのレスポンスタイムが遅い  • PHPの新しい機能や記法を使いたい   
→　PHP8.1 にして全部解決や！  なぜPHPバージョンアップをしたかったか？ 

13 • PHPのセキュリティサポート懸念  • 導入しようとしたライブラリでPHP7.x以上が条件  • 運用ツールのレスポンスタイムが遅い  • PHPの新しい機能や記法を使いたい   
→　PHP8.1 にして全部解決や！    ただし、期間は6ヶ月。  2023年1月スタートで2023年6月末にリリースしたい。  なぜなら7月末に周年イベントで負荷が高くなる。  その1ヶ月前までには、PHP8.1を安定動作させておきたい。  なぜPHPバージョンアップをしたかったか？ 

14 開発方針 

15 • 修正対象箇所の洗い出し  ◦ PHP_CodeSniffer を使ってPHP8.1のコード記法に適していない箇所を洗い出した  • ひととおり修正し終わったあとで、ユニットテストを実施  まず修正箇所を洗い出そう！ 

16 • 洗い出した修正箇所:196件  ◦ error:130件  ◦ warning:66件    まずはこれを足がかりに進めることに  まず修正箇所を洗い出そう！ 
   

17 PHP8.1対応を平和に進めるための戦略  PHP8.1開発はPHP8.1専用のブランチで開発していた   

18 PHP8.1開発はPHP8.1専用のブランチで開発していた    開発期間中はPHP8.1バージョンアップだけでなく、PHP5.5  で新イベントや追加機能の開発も並行で行われる  PHP8.1対応を平和に進めるための戦略  PHP5.5での追加機能  

19 PHP5.5での追加機能についてもPHP8.1対応する必要があるため、定期的にPHP8.1用ブランチに取り込みが必要となる    PHP8.1対応を平和に進めるための戦略  PHP5.5での追加機能  

20 PHP5.5での追加機能についてもPHP8.1対応する必要があるため、定期的にPHP8.1用ブランチに取り込みが必要となる  →ただし、PHP8.1のブランチは6ヶ月間という長い期間、開発が行われるため差分が大きくなる。      PHP8.1対応を平和に進めるための戦略  PHP5.5での追加機能  

21 PHP5.5での追加機能についてもPHP8.1対応する必要があるため、定期的にPHP8.1用ブランチに取り込みが必要となる  →ただし、PHP8.1のブランチは6ヶ月間という長い期間、開発が行われるため差分が大きくなる。  →差分が大きいとConflictする    PHP8.1対応を平和に進めるための戦略  PHP5.5での追加機能  

22 なので、なるべくPHP8.1ブランチの差分を小さくしたい。    PHP8.1対応を平和に進めるための戦略   

23 なので、なるべくPHP8.1ブランチの差分を小さくしたい。  →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなるべく少なくしていた。    PHP8.1対応を平和に進めるための戦略    PHP5.5でも動作する修正  

24 なので、なるべくPHP8.1ブランチの差分を小さくしたい。  →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなるべく少なくしていた。    PHP8.1対応を平和に進めるための戦略    PHP5.5でも動作する修正  
devブランチに入れて先にリリースする  

25 なので、なるべくPHP8.1ブランチの差分を小さくしたい。  →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなるべく少なくしていた。    PHP8.1対応を平和に進めるための戦略    PHP8.1対応の全体差分の  約50％を事前にリリース 

26 事前リリースした具体例 

27 count対応    事前リリースした具体例 count対応 

28 count対応    事前リリースした具体例 count対応 

29 count対応  • PHP8.0から配列やCountableオブジェクト以外を引数に渡すとエラーになるようになった  事前リリースした具体例 count対応 

30 count対応  • PHP8.0から配列やCountableオブジェクト以外を引数に渡すとエラーになるようになった  ◦ →配列やCountableオブジェクトになるよう引数を調整した。 PHP5.5の段階でも変えられるもの。  事前リリースした具体例 count対応 

31 PHPUnitはPHPのユニットテストフレームワーク    私たちの運用では、新しいコード変更が提案されるたび、PHPUnit でテストを行っている。  そして、そのテスト結果が問題ないことが確認された場合のみ、変更をマージする。  これによりコードの品質を維持している。    PHPUnitについて 

32 事前リリースした具体例 @expectedException の廃止  •  

33 • @expectedException アノテーション  ◦ PHPUnitで例外のテストを書きたい時に使用する  ◦ PHPUnit9 で廃止  事前リリースした具体例
@expectedException の廃止 

34 • @expectedException アノテーション  ◦ PHPUnitで例外のテストを書きたい時に使用する  ◦ PHPUnit9 で廃止  •
対応方法  /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止 

対応方法  /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止  古いPHPUnitでは  この書き方はできない  

対応方法  /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->setExpectedException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止  PHPUnit4.5でも使える setExpectedExceptionに書き換える 

対応方法  /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止  リリース時に  expectException に   一括置き換えする 

38 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった  ◦ PHPUnit6で追加  事前リリースした具体例名前空間対応 

39 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった  ◦ PHPUnit6で追加  • 対応方法 
事前リリースした具体例名前空間対応    -class BleachUnitTestCase extends PHPUnit_Framework_TestCase +class BleachUnitTestCase extends PHPUnit\Framework\TestCase {

40 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった  ◦ PHPUnit6で追加  • 対応方法 
      • エイリアスを使うことでPHPUnit4.5でも名前空間っぽい記載ができる  事前リリースした具体例名前空間対応    -class BleachUnitTestCase extends PHPUnit_Framework_TestCase +class BleachUnitTestCase extends PHPUnit\Framework\TestCase { +class_alias('PHPUnit_Framework_TestCase', 'PHPUnit\Framework\TestCase');

41 後回しにしたこと 

42 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応    • PHP7.3からMCrypt削除されたためOpenSSLに移行    • xhprof代替の新パフォーマンスモニタリングの導入 
  • PHPUnit10でwithConsecutiveの廃止 

43 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応    • PHP7.3からMCrypt削除されたためOpenSSLに移行。    • 新パフォーマンスモニタリングの導入（xhprof代替） 
  • PHPUnit10でwithConsecutiveの廃止    締め切りに間に合わない！   

44 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応    • PHP7.3からMCrypt削除されたためOpenSSLに移行。    • 新パフォーマンスモニタリングの導入（xhprof代替） 
  • PHPUnit10でwithConsecutiveの廃止 

45 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応  → バッチ処理は独立しているため、後日1つずつPHP8.1対応。  • PHP7.3からMCrypt削除されたためOpenSSLに移行。    •
新パフォーマンスモニタリングの導入（xhprof代替）    • PHPUnit10でwithConsecutiveの廃止 

46 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応  → バッチ処理は独立しているため、後日1つずつPHP8.1対応。  • PHP7.3からMCrypt削除されたためOpenSSLに移行。  →PECLでMCryptをインストールして一旦使い続ける  •
新パフォーマンスモニタリングの導入（xhprof代替）    • PHPUnit10でwithConsecutiveの廃止 

47 PHPバージョンアップはやることが多い  • ゲームサーバだけでなく、バッチ処理もPHP8.1対応  → バッチ処理は独立しているため、後日1つずつPHP8.1対応。  • PHP7.3からMCrypt削除されたためOpenSSLに移行。  →PECLでMCryptをインストールして一旦使い続ける  •
新パフォーマンスモニタリングの導入（xhprof代替）  →リリース後に考える  • PHPUnit10でwithConsecutiveの廃止 

48 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応  → バッチ処理は独立しているため、後日1つずつPHP8.1対応。  • PHP7.3からMCrypt削除されたためOpenSSLに移行。  →PECLでMCryptをインストールして一旦使い続ける  • 新パフォーマンスモニタリングの導入（xhprof代替） 
→リリース後に考える  • PHPUnit10でwithConsecutiveの廃止  →一旦削除    PHPバージョンアップはやることが多い 

49 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応  → バッチ処理は独立しているため、後日1つずつ8.1対応。  • PHP7.3からMCrypt削除されたためOpenSSLに移行。  →PECLでMCryptをインストールして一旦使い続ける  • 新パフォーマンスモニタリングの導入（xhprof代替） 
→リリース後に考える  • PHPUnit10でwithConsecutiveの廃止  →一旦削除      PHPバージョンアップはやることが多い  ＃あとでやる  やることはたくさんあるので、   必須で対応しなければならないことに集中する  

50 運用中プロジェクトで  PHP8.1切り替えを  どう進行したか 

51 1. 開発環境について 2. どう進行したか？ 3. 運用環境での出た問題  運用中プロジェクトでPHP8.1切り替えをどう進行したか 

52 通常運用時のフロー  1. 開発環境について 

53 通常運用時のフロー  1. 開発環境について  ① 開発者やデバッグチームは開発環境にアップロードされたマスタデータを   元にプログラムを開発したり、データをチェックしたりします。
 

54 通常運用時のフロー  1. 開発環境について  ② チェックし終わったデータは本番DBにアップロードされ、プレイヤーは新しいキャラクターやイベントが遊べるようになります  

55 いきなりPHP8.1に切り替えてしまうと  1. 開発環境について  ①デバッグ中の不具合を見つけても、 PHP8.1が原因なのかマスタデータが原因なのかの切り分けが難しくなります。  

56 いきなりPHP8.1に切り替えてしまうと  1. 開発環境について  ② データ準備やチェックに遅れがでて、定常運用に影響がでてしまいます  

57 PHP8.1用のエンドポイントを準備して並行で動作  2. どう進行したか？ 

58 PHP8.1用のエンドポイントを準備して並行で動作  2. どう進行したか？  ① 定常運用のデバッグはPHP5.5でチェックするため影響なし  

59 PHP8.1用のエンドポイントを準備して並行で動作  2. どう進行したか？  ② 定常運用を止めずに並行してPHP8.1 の検証を進めることができた  

60 3. 運用環境で出た問題  　 

61 3. 運用環境で出た問題(MessagePackの変更)  　 

62 MessagePackとは  3. 運用環境で出た問題(MessagePackの変更) 

63 3. 運用環境で出た問題(MessagePackの変更)  なにが起こったか？ 

64 3. 運用環境で出た問題(MessagePackの変更)  なにが起こったか？  →DBからのデータ読み込みに失敗するようになった   

65 3. 運用環境で出た問題(MessagePackの変更)  なにが起こったか？  →DBからのデータ読み込みに失敗するようになった  なぜ？   

66 3. 運用環境で出た問題(MessagePackの変更)  なにが起こったか？  →DBからのデータ読み込みに失敗するようになった  なぜ？  →失敗していたのはMessagePackを使用していた箇所。   　msgpackのバージョンアップ0.5.5 ->
2.2.0 の際  文字列の新シリアライズ方式(str8)が採用されたため。   

67 3. 運用環境で出た問題(MessagePackの変更)  なにが起こったか？  →DBからのデータ読み込みに失敗するようになった  なぜ？  →失敗していたのはMessagePackを使用していた箇所。   　msgpackのバージョンアップ0.5.5 ->
2.2.0 の際  文字列の新シリアライズ方式(str8)が採用されたため。  　新しいバージョンで保存したデータを古いバージョンで  　読み込むことができなくなった  　（msgpack v0.5.6から変わった）   

68 暫定対処  3. 運用環境で出た問題(MessagePackの変更) 

69 暫定対処並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする         3. 運用環境で出た問題(MessagePackの変更) 

70 暫定対処並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする msgpack 0.5.5も 2.2.0 も同じデータ形式で保存される      
  3. 運用環境で出た問題(MessagePackの変更) 

71 暫定対処並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする msgpack 0.5.5も 2.2.0 も同じデータ形式で保存される      
  3. 運用環境で出た問題(MessagePackの変更)  php.ini msgpack.use_str8_serialization = Off

72 PHP8.1バージョンアップ後に起こったトラブル 

73 バグ修正のためプログラムを本番環境にデプロイした際  約3%の確率でSegmentation fault が起こるようになった。  巨大PHPファイルのJITが時々壊れる問題 

74 バグ修正のためプログラムを本番環境にデプロイした際  約3%の確率でSegmentation fault が起こるようになった。    →バグ修正したプログラムが原因かと考えRevertしてデプロイするも解消せず    巨大PHPファイルのJITが時々壊れる問題 
 

75 バグ修正のためプログラムを本番環境にデプロイした際  約3%の確率でSegmentation fault が起こるようになった。    →バグ修正したプログラムが原因かと考えRevertしてデプロイするも解消せず  →Webサーバの再起動をするとなぜか解消した   
巨大PHPファイルのJITが時々壊れる問題   

76 バグ修正のためプログラムを本番環境にデプロイした際  約3%の確率でSegmentation fault が起こるようになった。    →バグ修正したプログラムが原因かと考えRevertしてデプロイするも解消せず  →Webサーバの再起動をするとなぜか解消した  →
$a = 1 + 1; のような関係ない差分をデプロイしても発生  巨大PHPファイルのJITが時々壊れる問題 

77 色々調査したところ特定ファイルを本番環境にデプロイしたときだけ発生することがわかった    巨大PHPファイルのJITが時々壊れる問題 

78 色々調査したところ特定ファイルを本番環境にデプロイしたときだけ発生することがわかった  そのファイルがプロジェクトの中で一番大きい  PHPファイル（8000行超、360KB）    巨大PHPファイルのJITが時々壊れる問題 

79 色々調査したところ特定ファイルを本番環境にデプロイしたときだけ発生することがわかった  そのファイルがプロジェクトの中で一番大きい  PHPファイル（8000行超、360KB）  二番目に大きいPHPファイル（4000行超え、140KB）では再現せず    巨大PHPファイルのJITが時々壊れる問題 

80 色々調査したところ特定ファイルを本番環境にデプロイしたときだけ発生することがわかった  そのファイルがプロジェクトの中で一番大きい  PHPファイル（8000行超、360KB）  二番目に大きいPHPファイル（4000行超え、140KB）では再現せず    サーバ再起動すれば解決するが、このままデプロイする度に再起動するのは運用コストがかかるため対策したい... 
巨大PHPファイルのJITが時々壊れる問題 

81 対策  opcache.jit の設定をOFFにすることで解決した    巨大PHPファイルのJITが時々壊れる問題 

82 対策  opcache.jit の設定をOFFにすることで解決した    なぜかはわからない。初回コンパイル時の挙動に関連?  （わかる人いたら教えてください）       
    巨大PHPファイルのJITが時々壊れる問題 

83 対策  opcache.jit の設定をOFFにすることで解決した    なぜかはわからない。初回コンパイル時の挙動に関連?  （わかる人いたら教えてください）    opcache.jit をOFFにすることでレスポンスタイムは多少悪化した
（3%くらい）  巨大PHPファイルのJITが時々壊れる問題 

84 対策  opcache.jit の設定をOFFにすることで解決した    なぜかはわからない。初回コンパイル時の挙動に関連?  （わかる人いたら教えてください）    opcache.jit をOFFにすることでレスポンスタイムは多少悪化した
（3%くらい）  予め適切なファイルサイズに分割するのが良いので、大きなPHP ファイルがあるプロジェクトは注意しましょう。  （自分たちは今後のアップデートで分割予定）  巨大PHPファイルのJITが時々壊れる問題 

85 アプリのバージョンアップの際の実機デバッグテストでNGとなり、バグ報告がきたもの。  そのテスト内容が    PHP8.1速すぎ問題 

86 アプリのバージョンアップの際の実機デバッグテストでNGとなり、バグ報告がきたもの。  そのテスト内容が  タイムアウトの動作チェックテスト  タイムアウトまでの条件を1秒に変更するとサーバの処理待ちで1秒以上かかりタイムアウトする       
PHP8.1速すぎ問題 

87 アプリのバージョンアップの際の実機デバッグテストでNGとなり、バグ報告がきたもの。  そのテスト内容が  タイムアウトの動作チェックテスト  タイムアウトまでの条件を1秒に変更するとサーバの処理待ちで1秒以上かかりタイムアウトする  →早くなりすぎてタイムアウトしなかった（テストNG）    PHP8.1速すぎ問題 

88 アプリのバージョンアップの際の実機デバッグテストでNGとなり、バグ報告がきたもの。  そのテスト内容が  タイムアウトの動作チェックテスト  タイムアウトまでの条件を1秒に変更するとサーバの処理待ちで1秒以上かかりタイムアウトする  →早くなりすぎてタイムアウトしなかった（テストNG）  （レスポンスデータを10倍くらいになるよう所持キャラを増やしてなんとか通過） 
PHP8.1速すぎ問題 

89 数値で見る実績と効果 

90 • 164人日  ◦ リーダ：1名（26人日）  ◦ メインの実装担当：1名（71人日）  ◦ インフラ等相談役：3名（42人日+10人日+15人日）  工数 

91 スケジュール（実績） 

92 バージョン情報  5.5.13  バージョンアップ前  8.1.13  バージョンアップ後  PHP  4.5  10.3  PHPUnit
  1.4.10  3.7.2  PHP_CodeSniffer  0.5.5  2.2.0  msgpack 

93 PHP8.1バージョンアップのプログラム修正量  • PHP8.1バージョンアップによるプログラム修正量  +16823 追加 -17638 削除  

94 PHP8.1バージョンアップのプログラム修正量  • PHP8.1バージョンアップによるプログラム修正量  +16823 追加 -17638 削除 • 修正箇所の内訳は？ 

95 PHP8.1バージョンアップのプログラム修正量   

96 PHP8.1バージョンアップのプログラム修正量    全体の67％が  テストコードの修正だった。    

97 PHP8.1バージョンアップのプログラム修正量    全体の67％が  テストコードの修正だった。   PHPUnit対応が大変だった  

98 バグチケット件数    • デバッグ期間中に報告されたバグチケットは2件だけ  ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの修正に起因するものはなかった。

99 バグチケット件数  • デバッグ期間中に報告されたバグチケットは2件だけ  ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの修正に起因するものはなかった。  ◦ →ユニットテストを通す過程で、PHP_CodeSnifferでは検知できていなかった修正漏れなどが見つかり対応できた。 
◦ → デバッグ前にユニットテストを通したことで、修正必要な部分は対応しきれていた。 

100 バグチケット件数    • デバッグ期間中に報告されたバグチケットは2件だけ  ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの修正に起因するものはなかった。  ◦ →ユニットテストを通す過程で、PHP_CodeSnifferでは検知でき
ていなかった修正漏れなどが見つかり対応できた。  ◦ → デバッグ前にユニットテストを通したことで、修正必要な部分は対応しきれていた。  ◦ ユニットテストのバージョンアップは大変だけど大切 

101 • ゲームサーバAPIの平均レスポンスタイム  ◦ 0.238 秒 → 0.139秒 (42％改善) バージョンアップの効果 
PHP8.1切り替えタイミング  

102 • ユニットテストの処理時間  ◦ アプデ前後で変更のなかったテストを一部抽出  ◦ 496秒 → 247秒 (50％改善) 
バージョンアップの効果 

103 • 運用ツールのレスポンスタイム  ◦ 40％改善  バージョンアップの効果   

104 まとめ 

105 開発方針  • PHP_CodeSniffer を使ってPHP8.1のコード記法に適していない箇所を洗い出した  • ひととおり修正し終わったあとで、ユニットテストを実施  • PHP5.5でも動作するものは事前にリリースすることでPHP8.1ブ
ランチの差分を最小にし、Conflictリスクを低下  まとめ 

106 運用中プロジェクトでPHP8.1切り替えをどう進行したか  • PHP8.1用サーバのエンドポイントを分けることで、並行して運用  • MessagePackのバージョンアップで新シリアライズ形式が採用されたことによるデータ読み込み失敗については、並行運用期間中だけ設定をOFFにした  まとめ 

107 バージョンアップ後に起こったトラブル  • 本番環境デプロイ時に3%の確率でSegmentation faultが発生する障害  ◦ opcache.jit の設定をOFFにすることで暫定対応  •
PHP8.1が早すぎてタイムアウトのテストができない問題  ◦ キャラ数を10倍に増やすことで対応  まとめ 

108 数値で見る実績と効果  • 164人日  • ゲームサーバ 42％改善  • ユニットテスト 50％改善 
• 運用ツール 40％改善  まとめ 

109 まとめ  PHPバージョンアップの修正箇所  • 全体の67％がテストコードの修正だった  • テストを通す過程で、PHP_CodeSnifferでは検知できていなかった箇所などが見つかり対応できた。  • テストコードのおかげで、デバッグ時のバグが抑えられた。 
◦ ユニットテストのバージョンアップは大変だけど大切 

110 今回事前リリースした部分は、もっと前から準備できた部分だった。  実際に修正箇所の約50％を事前リリースにできた。  164人日を確保するのはプロジェクトによっては難しい。  ただ、事前リリース分をコツコツ対応していくのは可能。  バージョンアップしたいを思っている方は、  「PHP_CodeSnifferでチェックをする」や「PHPUnitのリリースノートを見てみる」など30分でできることから始めるとアップデートコストが減るのでやっていきましょう！ 
  さいごに 

111 ここまで聞いていただき、  ありがとうございました。  おわり 

運用中の大規模オンラインゲームで8年ぶりにPHPバージョンアップをした話

運用中の大規模オンラインゲームで8年ぶりにPHPバージョンアップをした話

Other Decks in Technology

Featured

Transcript