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

Transcript

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

   【オンライン】関西PHP勉強会

   2020.05.16

   清家史郎

   (@seike460)

   1

   

   View Slide

2. 2

   アジェンダ

   1. 自己紹介

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

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

   4. 非推奨を洗い出す

   5. まとめ

   

   View Slide

3. 01
   自己紹介

   

   View Slide

4. 自己紹介

   清家史郎

   @seike460

   - 清家史郎 (@seike460)

   - Fusic Co., Ltd. / evangelist / Engineer

   - バックエンド寄りフルスタック

   ■ PHP,Go,AWSが得意、Serverlessに興味
   

   - 技術コミュニティに関わるのが好き

   - カンファレンス登壇多数

   - PHPカンファレンス福岡 2020

   ■ 幻の実行委員長

   - Serverless Days Fukuoka 2019

   ■ co-chair

   4

   

   View Slide

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

   

   View Slide

6. 6

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

   状況 1

   現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）
   

   

   

   

   View Slide

7. 7

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

   状況 1

   現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）
   

   

   

   状況 2

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

   

   View Slide

8. 8

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

   状況 1

   現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）
   

   

   

   状況 3

   PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない
   

   状況 2

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

   

   View Slide

9. バージョンアップへの課題感

   - 動作保証は手動テストでカバー可能だが、毎回は辛い

   - 膨大かつ単純な作業ゆえ、単純なケアレスミスが不安

   

   ➔ 最小工数のテスト記述で最低限動作を保証したい

   ◆ テストのスコープを絞る

   

   ➔ 非推奨を潰すことがメイン作業

   ◆ 機械的な作業に落とし込む

   9

   

   View Slide

10. 10

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

    状況 1

    現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）
    

    

    

    状況 3

    PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない
    

    作戦

    - 最小工数で広い範囲をカバーできるテストを書く
    

    - 機械的な作業に落とし込む

    状況 2

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

    

    View Slide

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

    

    View Slide

12. 12

    テストのスコープを決める

    ● UI

    ○ 担保出来る範囲は一番広い

    ○ メンテナンスコストが高い

    ○ 実行時間が長い(PHPUnit+αが必要)

    ● Service

    ○ PHPの一連の動作は担保出来る

    ○ メンテナンスコストは中程度⚠

    ○ 実行時間も短め(PHPUnit内で完結)

    ● Unit

    ○ 担保出来る範囲は極小(メソッド単位)

    ■ 一方で詳細まで確認可能

    ○ メンテナンスコストは非常に低い

    ○ 実行時間も短い

    テストピラミッド

    

    上に行くほど

    - 再現度は高い

    - 実行時間が長い

    - 保守、デバッグの労力増大

    

    一般的にUnit部分を充実させる

    

    View Slide

13. 13

    テストのスコープを決める

    ● UI

    ○ Cypress or phpunit-selenium

    ■ 実行時間やテストピラミッドの原則

    カバレッジ率がわからない

    ● Service　⭕ここの充実を選択

    ○ CakePHPのControllerを網羅

    ■ 広範囲のカバレッジを確保出来る

    ● Unit

    ○ CakePHPのModel等を網羅

    ■ カバレッジの確保には工数が必要

    Controller網羅後

    - UIは手動テストを実行

    - カバレッジや優先順位を元にUnitテストも増やす

    ※変更し辛いタイミングなので諸刃の剣

    

    View Slide

14. 04
    非推奨を洗い出す

    

    View Slide

15. 15

    非推奨を洗い出す

    PHPStanで検出出来るみたいだけどコードの品質も保ちたい…

    ● scrutinizer

    ○ 静的解析を自動的に行ってくれるサービス(privateは有料)

    ● ここに表示される「Duplication」をひたすらに消していく

    scrutinizer
    

    View Slide

16. 16

    grep | xargs sedで一括置換

    ● scrutinizerにて修正内容は確定してくるので関数を変更していきます

    $ grep -rl 'hoge' src | xargs sed -i -e 's/hoge/getHoge/g'
    ● 一括変換の結果はgit diffで確認しながら意図した置換になってるかを確認

    ○ 特に get〇〇、set〇〇系の修正はミスが発生しやすいので注意

    間違えていた場合は一つ一つ手作業で丁寧に変更していきます

    ● 全てを手作業だと 気が狂いそう 効率が悪いので一斉置換を行います。

    みんな大好きsedコマンドを利用します。

    

    

    

    View Slide

17. 17

    まとめ

    Point 1

    開発工数が限られている為、テストピラミッドの原則にとらわれず
    

    テストのスコープを決めて、手動テストと組み合わせて品質を確保
    

    Point 2

    scrutinizerを利用して、修正箇所及び修正内容を確認。
    

    一括置換を行うことにより機械的な修正
    

    summary

    「正論」だけでは戦えない状況も現実と向き合い、
    

    現状に即した施策で少しづつ改善していく事が大事
    

    extras

    fixtureをDB + Fakerで自動生成したりもしたが時間の関係で割愛
    

    associationを参照しながらFakerでデータ保護したfixture生成Shellを書いた
    

    

    View Slide

18. ご清聴いただき

    ありがとうございました

    Thank You
    http://recruit.fusic.co.jp

    

    View Slide