CakePHPのバージョンアップ戦略 【オンライン】関西PHP勉強会 2020.05.16 清家史郎 (@seike460) 1
View Slide
2 アジェンダ 1. 自己紹介 2. バージョンアッププロジェクト状況 3. テストのスコープを決める 4. 非推奨を洗い出す 5. まとめ
01自己紹介
自己紹介 清家史郎 @seike460 - 清家史郎 (@seike460) - Fusic Co., Ltd. / evangelist / Engineer - バックエンド寄りフルスタック ■ PHP,Go,AWSが得意、Serverlessに興味 - 技術コミュニティに関わるのが好き - カンファレンス登壇多数 - PHPカンファレンス福岡 2020 ■ 幻の実行委員長 - Serverless Days Fukuoka 2019 ■ co-chair 4
02バージョンアッププロジェクト状況
6 バージョンアッププロジェクト状況 状況 1 現職で初めて携わった受託開発プロジェクト(圧倒的エクスキューズ)
7 バージョンアッププロジェクト状況 状況 1 現職で初めて携わった受託開発プロジェクト(圧倒的エクスキューズ) 状況 2 Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)
8 バージョンアッププロジェクト状況 状況 1 現職で初めて携わった受託開発プロジェクト(圧倒的エクスキューズ) 状況 3 PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない 状況 2 Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)
バージョンアップへの課題感 - 動作保証は手動テストでカバー可能だが、毎回は辛い - 膨大かつ単純な作業ゆえ、単純なケアレスミスが不安 ➔ 最小工数のテスト記述で最低限動作を保証したい ◆ テストのスコープを絞る ➔ 非推奨を潰すことがメイン作業 ◆ 機械的な作業に落とし込む 9
10 バージョンアッププロジェクト状況 状況 1 現職で初めて携わった受託開発プロジェクト(圧倒的エクスキューズ) 状況 3 PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない 作戦 - 最小工数で広い範囲をカバーできるテストを書く - 機械的な作業に落とし込む 状況 2 Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)
03テストのスコープを決める
12 テストのスコープを決める ● UI ○ 担保出来る範囲は一番広い ○ メンテナンスコストが高い ○ 実行時間が長い(PHPUnit+αが必要) ● Service ○ PHPの一連の動作は担保出来る ○ メンテナンスコストは中程度⚠ ○ 実行時間も短め(PHPUnit内で完結) ● Unit ○ 担保出来る範囲は極小(メソッド単位) ■ 一方で詳細まで確認可能 ○ メンテナンスコストは非常に低い ○ 実行時間も短い テストピラミッド 上に行くほど - 再現度は高い - 実行時間が長い - 保守、デバッグの労力増大 一般的にUnit部分を充実させる
13 テストのスコープを決める ● UI ○ Cypress or phpunit-selenium ■ 実行時間やテストピラミッドの原則 カバレッジ率がわからない ● Service ⭕ここの充実を選択 ○ CakePHPのControllerを網羅 ■ 広範囲のカバレッジを確保出来る ● Unit ○ CakePHPのModel等を網羅 ■ カバレッジの確保には工数が必要 Controller網羅後 - UIは手動テストを実行 - カバレッジや優先順位を元にUnitテストも増やす ※変更し辛いタイミングなので諸刃の剣
04非推奨を洗い出す
15 非推奨を洗い出す PHPStanで検出出来るみたいだけどコードの品質も保ちたい… ● scrutinizer ○ 静的解析を自動的に行ってくれるサービス(privateは有料) ● ここに表示される「Duplication」をひたすらに消していく scrutinizer
16 grep | xargs sedで一括置換 ● scrutinizerにて修正内容は確定してくるので関数を変更していきます $ grep -rl 'hoge' src | xargs sed -i -e 's/hoge/getHoge/g'● 一括変換の結果はgit diffで確認しながら意図した置換になってるかを確認 ○ 特に get〇〇、set〇〇系の修正はミスが発生しやすいので注意 間違えていた場合は一つ一つ手作業で丁寧に変更していきます ● 全てを手作業だと 気が狂いそう 効率が悪いので一斉置換を行います。 みんな大好きsedコマンドを利用します。
17 まとめ Point 1 開発工数が限られている為、テストピラミッドの原則にとらわれず テストのスコープを決めて、手動テストと組み合わせて品質を確保 Point 2 scrutinizerを利用して、修正箇所及び修正内容を確認。 一括置換を行うことにより機械的な修正 summary 「正論」だけでは戦えない状況も現実と向き合い、 現状に即した施策で少しづつ改善していく事が大事 extras fixtureをDB + Fakerで自動生成したりもしたが時間の関係で割愛 associationを参照しながらFakerでデータ保護したfixture生成Shellを書いた
ご清聴いただき ありがとうございました Thank Youhttp://recruit.fusic.co.jp