Download as PDF, PPTX
More Related Content
PHPアプリの品質を(ある程度)保つために出来る事 〜組織編〜
- 1. PHPアプリの品質を(ある程度) 保つために出来る事 〜～組織編〜～ PHP カンファレンス 2017 2017/10/08 株式会社 サイバード 三浦 克浩
- 2. ⾃自⼰己紹介 • 名前：三浦 克浩 • Twitter ID：@MiuraKatsu • 仕事：恋愛ゲーム • 好きなフレームワーク： Laravel、Sails.js • 浦和レッズ：
- 3.
- 4. • シリーズ 通算14タイトル •海外展開 5カ国 6タイトル • シリーズ以外 4タイトル • 展開プラットフォーム 14プラットフォーム ⼥女性向け恋愛ノベルゲーム
- 5. 前提 • 新規開発じゃなくて、既存運⽤用の話 •ソシャゲ運⽤用＝毎⽉月なんかしらイベントがある • サーバサイド(PHP)の話中⼼心 • コードをどう変えるか？じゃなくて変えるため に何をしたのか？
- 6. • タイトル毎に運⽤用チー ム •それぞれチームリーダ とメンバー • １チーム３〜～６⼈人 • 海外は別チームの場合 も 全体で５０〜～８０⼈人のエンジニア
- 7.
- 8. 品質をよくするには？ • 神がコードを書けば品質が良くなる • 神がコードレビューをすれば品質が良くなる •神だけがコードを書けば品質が良くなる • 神がコードを書いた部分だけ品質が良くなる • 神がすべてのコードレビューをすれば品質が 良くなる
- 9.
- 10.
- 11.
- 12. 何をしたか？ • 横断チームの新設 •開発運⽤用サイクルの改善 • 品質評価軸の可視化 • 専⾨門チームの組成
- 13.
- 14. 横断チームの役割 • 共通系システムの維持メンテ •各チーム間の交流のHub • ⽇日々のカイゼンだけではできないことをする
- 15. 何をしたか？ • 横断チームの新設 •開発運⽤用サイクルの改善 • 品質評価軸の可視化 • 専⾨門チームの組成
- 16. Development -‐‑‒ VCS(Git)によるソース管理 Deploy -‐‑‒ ⾃自動デプロイ Service Monitoring -‐‑‒ ステータス監視 開発運⽤用サイクルの改善 横断チームが仕組み導⼊入
- 17. Development -‐‑‒ VCS(Git)によるソース管理 -‐‑‒ Pull Request 運⽤用 Code Check -‐‑‒ コードレビュー -‐‑‒ コーディング規約 Deploy -‐‑‒ ⾃自動デプロイ Service Monitoring -‐‑‒ ステータス監視 -‐‑‒ パフォーマンス監視 開発運⽤用サイクルの改善
- 18. Development -‐‑‒ VCS(Git)によるソース管理 -‐‑‒ Pull Request 運⽤用 Code Check -‐‑‒ コードレビュー -‐‑‒ コーディング規約 Test -‐‑‒ Syntax チェック -‐‑‒ ユニットテスト -‐‑‒ 継続的インテグレーション Deploy -‐‑‒ ⾃自動デプロイ Service Monitoring -‐‑‒ ステータス監視 -‐‑‒ パフォーマンス監視 開発運⽤用サイクルの改善 ユニットテストよりCIが先
- 19. Development -‐‑‒ VCS(Git)によるソース管理 -‐‑‒ Pull Request 運⽤用 Code Check -‐‑‒ コードレビュー -‐‑‒ コーディング規約 -‐‑‒ 静的解析 Test -‐‑‒ Syntax チェック -‐‑‒ ユニットテスト -‐‑‒ 継続的インテグレーション Deploy -‐‑‒ ⾃自動デプロイ Service Monitoring -‐‑‒ ステータス監視 -‐‑‒ パフォーマンス監視 -‐‑‒ プロファイリング 開発運⽤用サイクルの改善
- 20. •運⽤用チームで取り組みづらい事を横断チームが 仕組み化・⾃自動化 •⾃自動化できたところに乗っかってもらう →導⼊入コストを下げる •横断チームが作ることで標準化される •あるんだから使ってよね、というプレッシャー 開発運⽤用サイクルの改善
- 21. GitHubでソース管理する →PullReq運⽤用ができる →→PullReqがくるからコードレビューする ⾃自動デプロイする →デプロイの前にCIが回せる →→CIが回るからユニットテスト書く 開発運⽤用サイクルの改善 • 仕組みを⼊入れることで⾏行動が変わる
- 22.
- 23.
- 24.
- 25. 何をしたか？ • 横断チームの新設 •開発運⽤用サイクルの改善 • 品質評価軸の可視化 • 専⾨門チームの組成
- 26. 品質を定義する • サービス的な品質：レスポンスが早い。サーバ 負荷が軽い。 •コード的な品質：静的解析のスコアが⾼高い。テ ストカバレッジが⾼高い。 数値化できるものを計測する
- 27. 品質評価軸の可視化 • 評価軸をチーム(タイトル)毎に可視化して公開 •静的解析スコア/テストカバレッジ/スロークエリー 発⽣生数/レスポンスタイム/etc • ⾃自チームの数字が⾒見えるようになる： →⾃自分事になる • 他チームの数字が⾒見えるようになる： →勝⼿手に競い合う
- 28. サービス的な評価軸計測 • Zabbix ：統合監視ツール。計測値の可視化 •NewRelic：SaaS型パフォーマンス監視(有料) • Monyog：MySQLモニタリングツール(有料) パフォーマンス監視＆プロファイリング
- 29. コード的な評価軸計測 • Scrutinizer：静的解析SaaS(有料) •SonarQube：静的解析ツール • Coveralls：カバレッジレポート(有料) 単純に⾼高ければ⾼高評価でもない 古いタイトルには負の遺産も多い 変化を⾒見ている
- 30. 可視化 • Zabbix/NewRelic：時系列でグラフ表⽰示 •Chatwork：Alert/CI結果を通知 • Wiki：バッチリスト。こんなやつ→
- 31. 何をしたか？ • 横断チームの新設 •開発運⽤用サイクルの改善 • 品質評価軸の可視化 • 専⾨門チームの組成
- 32. 優先度 • レスポンスが早くなると、売上は上がる •スコアが上がっても、売上は上がらない まずはサービス品質の改善から
- 33.
- 34. • インフラチーム •インフラチーム内にDBA
- 35. SQL道場 • 毎週DBAによるSQL指導 •今週発⽣生したスロークエリー数の報告 • 今週発⽣生したイケてないクエリーについての 指導
- 36. ORMの功罪 • PHPerにはSQLが分からぬ •かならずDB操作をしなければならぬ • 功：PHPerでもDB操作ができる！ • 罪：どんなクエリが吐かれるか、吐いてみない と分からない
- 37. DBAとの対話 • DBAはクエリーしか⾒見ない •プログラムの内容は知らない • ゲーム仕様も知らない • 開発者の⾔言い訳に同情しない
- 38. インフラ担当との対話 • インフラはサーバ負荷しか⾒見ない •負荷理由（exイベント開始）を知らない • サーバ増はコスト増 • 開発者の⾔言い訳に同情しない
- 39.
- 40.
- 41. 改善⽅方法はひとつじゃない • クエリーを修正する •プログラムを修正する • サーバをスケールアウト/スケールアップする • RDBからKVSに切替える • ゲーム仕様を変更する
- 42.
- 43. まとめ • 運⽤用だからカイゼンできる •仕組みを変えると⾏行動が変わる • 「推測するな。計測せよ」 • ⾒見える化⼤大事 • 開発者以外を巻き込む
- 44.
- 45.