はじめてのDBバージョンアップをする機会があったので、やったことをまとめておきます。

前提

MySQL5.6->8.0へのバージョンアップ
対象はPHPで書かれた業務システム

流れ

全体の流れは以下。

バージョンアップ前後の環境で単体テスト実行、エラーの有無確認
エラーがあれば修正
動作確認・パフォーマンステスト

バージョンアップ前後の環境で単体テスト実行

全クラスで単体テストを書いていてJenkinsで実行できる状態だったので、Jenkinsで実行するDBをバージョンアップ前・後で用意。

バージョンアップ前後のDB環境のコンテナをDockerで作成
DB環境作ったサーバをJenkinsの管理ノードに追加
Jenkinsプロジェクト設定でそれぞれ作ったコンテナのラベル式を設定

で、指定したバージョンのDBで実行できたので便利でした。
※ノードの追加参考：【Jenkins運用基本】Jenkinsの管理ノードに外部サーバを追加する手順 - そういうのがいいブログ

単体テストですべての処理が網羅されていることが前提ですが、
これで「バージョンアップ後にエラーにならないこと」の担保ができるのでテストの工数がぐっと減りました。CIは偉大ですね。

単体テストですべての処理が網羅されていること

これは単体テストのカバレッジが100%になっていれば網羅されているだろうという前提で進めました。
カバレッジは単に「その行を処理として通っているか」だけを見るので厳密に言うと違うのですが、まぁその辺は現実的なスケジュールを加味して、カバレッジである程度担保できるでしょうみたいな感じですね。
日頃からの単体テストの整備は大事です。

エラー修正

これは単体テストとDockerとJenkinsのおかげでサクサクできました。

エラー修正をpush
Jenkinsでテスト実行
新旧DB環境の結果確認
エラーあれば修正

を繰り返して修正していけばOK。
修正する度に手動で検証する…という手間が省けるのが素晴らしいですね。
また、Dockerでコンテナ作成しているので新旧環境の違いはDBバージョンだけ（のはず）なので、エラーの原因特定がしやすかったです。

動作確認・パフォーマンステスト

ここに一番時間をかけました。というかJenkinsのおかげでここに時間をかけられました。
本来は性能が上がるはずなので速くなりそうなものですが、

DBに新機能が追加された
DB側のバグが修正された
上述したエラー修正でクエリを変更した

などにより今まで速かったものが遅くなった…なんてこともあるのでパフォーマンステストは重要。

また、動作確認については基本的にJenkinsで単体テスト回してエラー無しであれば（=DB操作メソッドの入出力が変わっていなければ）OKという方針でしたが、

単体テストですべての処理が網羅されていること

これが確実に担保されているわけではないので、やはり動作確認は念のためしておきたい…という話に。
とはいえスケジュールも限られているので、パフォーマンステストで全機能各1回は実行するしその時エラーにならないことを確認しようということになりました。

パフォーマンステストの方は各画面・バッチで同じ処理を実行して実行時間を計測、新旧DBで比較し遅くなっていないかを確認することにしました。

観点としては以下。

対象選定
- 業務上重要度の高い機能：3回実行、平均実行時間を比較
- 業務上重要度の低い機能：1回実行、大きな遅延が無ければOK
画面処理
大体3秒以上の遅延が無ければOK。（業務システムなので業務に支障が出ない程度であればOK）
バッチ処理
件数が増えれば増えるほど遅延がかさむので、個別に処理件数と遅延時間を確認する。

例：1秒程度の遅延は問題なし、10秒以上の遅延は問題ありとする場合
1000件処理する可能性があるバッチ
a. 10件のデータ処理で0.1秒遅延している場合、 100件で1秒遅延、1000件で10秒遅延する
   →問題あり
b. 10件のデータ処理で0.01秒遅延している場合、 100件で0.1秒遅延、1000件で1秒遅延する
   →問題なし
MAX処理件数100件のバッチ
c. 10件のデータ処理で0.1秒遅延している場合、 100件で1秒遅延する
   →問題なし

実行時間の計測は

バッチ処理
開始時間と終了時間をテーブルで管理しているので、そこの差分で測る。
画面処理
Webサーバに吐き出しているログに画面処理の実行時間が出るので、それをtailコマンドで監視して確認。
tail -f [ファイル名] | grep "検索文字列"
tailコマンドについて詳しくまとめました【Linuxコマンド集】

という感じで、個人的にはtailコマンドで監視しながら作業するのがいかにも映画に出てくるプログラマー！って感じで楽しかったですねw

まとめ

今回特に大変だったのは、更新系処理のテストデータの用意でした。
特にバッチに処理させるテストデータは少なくとも10件くらいは必要だったので、作るのに結構手間がかかりました。
今回は見送ったのですが、画面から作れるデータはSeleniumを使う？みたいな話も出てました。流れましたが…
後になって思うと、やっぱりこれ使った方が良かったかも…。
10分で理解する Selenium - Qiita
次の機会に生かします。