CakePHPのバージョンアップ戦略

Transcript

1. CakePHPのバージョンアップ戦略
 【オンライン】関西PHP勉強会
 2020.05.16
 清家史郎
 (@seike460)
 1


2. 2
 アジェンダ
 1. 自己紹介
 2. バージョンアッププロジェクト状況
 3. テストのスコープを決める
 4. 非推奨を洗い出す


   5. まとめ


3. 01 自己紹介


4. 自己紹介
 清家史郎
 @seike460
 - 清家史郎 (@seike460)
 - Fusic Co., Ltd.

   / evangelist / Engineer
 - バックエンド寄りフルスタック
 ▪ PHP,Go,AWSが得意、Serverlessに興味 
 - 技術コミュニティに関わるのが好き
 - カンファレンス登壇多数
 - PHPカンファレンス福岡 2020
 ▪ 幻の実行委員長
 - Serverless Days Fukuoka 2019
 ▪ co-chair
 4


5. 02 バージョンアッププロジェクト状況


6. 6
 バージョンアッププロジェクト状況
 状況 1
 現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ） 
 
 


7. 7
 バージョンアッププロジェクト状況
 状況 1
 現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ） 
 
 
 状況 2


   Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済) 


8. 8
 バージョンアッププロジェクト状況
 状況 1
 現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ） 
 
 
 状況 3


   PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない 
 状況 2
 Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済) 


9. バージョンアップへの課題感
 - 動作保証は手動テストでカバー可能だが、毎回は辛い
 - 膨大かつ単純な作業ゆえ、単純なケアレスミスが不安
 
 ➔ 最小工数のテスト記述で最低限動作を保証したい
 ◆ テストのスコープを絞る


   
 ➔ 非推奨を潰すことがメイン作業
 ◆ 機械的な作業に落とし込む
 9


10. 10
 バージョンアッププロジェクト状況
 状況 1
 現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ） 
 
 
 状況 3


    PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない 
 作戦
 - 最小工数で広い範囲をカバーできるテストを書く 
 - 機械的な作業に落とし込む
 状況 2
 Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済) 


11. 03 テストのスコープを決める


12. 12
 テストのスコープを決める
 • UI
 ◦ 担保出来る範囲は一番広い
 ◦ メンテナンスコストが高い
 ◦ 実行時間が長い(PHPUnit+αが必要)


    • Service
 ◦ PHPの一連の動作は担保出来る
 ◦ メンテナンスコストは中程度⚠
 ◦ 実行時間も短め(PHPUnit内で完結)
 • Unit
 ◦ 担保出来る範囲は極小(メソッド単位)
 ▪ 一方で詳細まで確認可能
 ◦ メンテナンスコストは非常に低い
 ◦ 実行時間も短い
 テストピラミッド
 
 上に行くほど
 - 再現度は高い
 - 実行時間が長い
 - 保守、デバッグの労力増大
 
 一般的にUnit部分を充実させる


13. 13
 テストのスコープを決める
 • UI
 ◦ Cypress or phpunit-selenium
 ▪ 実行時間やテストピラミッドの原則


    カバレッジ率がわからない
 • Service　⭕ここの充実を選択
 ◦ CakePHPのControllerを網羅
 ▪ 広範囲のカバレッジを確保出来る
 • Unit
 ◦ CakePHPのModel等を網羅
 ▪ カバレッジの確保には工数が必要
 Controller網羅後
 - UIは手動テストを実行
 - カバレッジや優先順位を元にUnitテストも増やす
 ※変更し辛いタイミングなので諸刃の剣


14. 04 非推奨を洗い出す


15. 15
 非推奨を洗い出す
 PHPStanで検出出来るみたいだけどコードの品質も保ちたい…
 • scrutinizer
 ◦ 静的解析を自動的に行ってくれるサービス(privateは有料)
 • ここに表示される「Duplication」をひたすらに消していく
 scrutinizer

16. 16
 grep | xargs sedで一括置換
 • scrutinizerにて修正内容は確定してくるので関数を変更していきます
 $ grep -rl

    'hoge' src | xargs sed -i -e 's/hoge/getHoge/g' • 一括変換の結果はgit diffで確認しながら意図した置換になってるかを確認
 ◦ 特に get〇〇、set〇〇系の修正はミスが発生しやすいので注意
 間違えていた場合は一つ一つ手作業で丁寧に変更していきます
 • 全てを手作業だと 気が狂いそう 効率が悪いので一斉置換を行います。
 みんな大好きsedコマンドを利用します。
 
 


17. 17
 まとめ
 Point 1
 開発工数が限られている為、テストピラミッドの原則にとらわれず 
 テストのスコープを決めて、手動テストと組み合わせて品質を確保 
 Point 2


    scrutinizerを利用して、修正箇所及び修正内容を確認。 
 一括置換を行うことにより機械的な修正 
 summary
 「正論」だけでは戦えない状況も現実と向き合い、 
 現状に即した施策で少しづつ改善していく事が大事 
 extras
 fixtureをDB + Fakerで自動生成したりもしたが時間の関係で割愛 
 associationを参照しながらFakerでデータ保護したfixture生成Shellを書いた 


18. ご清聴いただき
 ありがとうございました
 Thank You http://recruit.fusic.co.jp