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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

01 自己紹介 

Slide 4

Slide 4 text

自己紹介  清家史郎  @seike460  - 清家史郎 (@seike460)  - Fusic Co., Ltd. / evangelist / Engineer  - バックエンド寄りフルスタック  ■ PHP,Go,AWSが得意、Serverlessに興味   - 技術コミュニティに関わるのが好き  - カンファレンス登壇多数  - PHPカンファレンス福岡 2020  ■ 幻の実行委員長  - Serverless Days Fukuoka 2019  ■ co-chair  4 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7  バージョンアッププロジェクト状況  状況 1  現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）       状況 2  Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)  

Slide 8

Slide 8 text

8  バージョンアッププロジェクト状況  状況 1  現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）       状況 3  PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない   状況 2  Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)  

Slide 9

Slide 9 text

バージョンアップへの課題感  - 動作保証は手動テストでカバー可能だが、毎回は辛い  - 膨大かつ単純な作業ゆえ、単純なケアレスミスが不安    ➔ 最小工数のテスト記述で最低限動作を保証したい  ◆ テストのスコープを絞る    ➔ 非推奨を潰すことがメイン作業  ◆ 機械的な作業に落とし込む  9 

Slide 10

Slide 10 text

10  バージョンアッププロジェクト状況  状況 1  現職で初めて携わった受託開発プロジェクト（圧倒的エクスキューズ）       状況 3  PHP, PostgreSQL, CakePHPのバージョンアップ工数は潤沢ではない   作戦  - 最小工数で広い範囲をカバーできるテストを書く   - 機械的な作業に落とし込む  状況 2  Unitテストは途中から書き始めたので新機能部分しかない(CI環境は整備済)  

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

13  テストのスコープを決める  ● UI  ○ Cypress or phpunit-selenium  ■ 実行時間やテストピラミッドの原則  カバレッジ率がわからない  ● Service　⭕ここの充実を選択  ○ CakePHPのControllerを網羅  ■ 広範囲のカバレッジを確保出来る  ● Unit  ○ CakePHPのModel等を網羅  ■ カバレッジの確保には工数が必要  Controller網羅後  - UIは手動テストを実行  - カバレッジや優先順位を元にUnitテストも増やす  ※変更し辛いタイミングなので諸刃の剣 

Slide 14

Slide 14 text

04 非推奨を洗い出す 

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17  まとめ  Point 1  開発工数が限られている為、テストピラミッドの原則にとらわれず   テストのスコープを決めて、手動テストと組み合わせて品質を確保   Point 2  scrutinizerを利用して、修正箇所及び修正内容を確認。   一括置換を行うことにより機械的な修正   summary  「正論」だけでは戦えない状況も現実と向き合い、   現状に即した施策で少しづつ改善していく事が大事   extras  fixtureをDB + Fakerで自動生成したりもしたが時間の関係で割愛   associationを参照しながらFakerでデータ保護したfixture生成Shellを書いた  

Slide 18

Slide 18 text

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