$30 off During Our Annual Pro Sale. View Details »

ローンチから16年目のWebサービスに、どうやってフィーチャートグルを導入したか、運用しているか / phpcon2022

meihei
September 24, 2022

ローンチから16年目のWebサービスに、どうやってフィーチャートグルを導入したか、運用しているか / phpcon2022

phpcon-2022

---
内容

- 弊社サービスにおけるフィーチャートグルを導入した効果
- フィーチャートグルの導入〜現在に至るまでの実装
- 導入後にテストを可能にするための改善

meihei

September 24, 2022
Tweet

More Decks by meihei

Other Decks in Programming

Transcript

  1. ローンチから16年目の Webサービスに、 どうやってフィーチャートグル を導入したか、 運用しているか。

  2. 自己紹介 名前: meihei(江間洋平) 所属: 株式会社PR TIMES Twitter: app1e_s GitHub: meihei3

    VTuberの配信を流して生きて います 2
  3. 今回が初登壇です🙌 3

  4. この発表の位置づけ 4

  5. 5 ローンチから16年目の Webサービスに、 どうやってフィーチャートグル を導入したか、 運用しているか。

  6. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 6
  7. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 7
  8. PR TIMESというサービスについて • プレスリリース配信サービス • 月間のサイト閲覧数 は6,000万PV 8

  9. その裏側は?(去年まで) • PHP x.x ( < 8.1 ) で動いている •

    触れるとすべてが崩壊する独自フレームワーク • テストなし • Namespaceなし • スーパーグローバル使いたい放題 9
  10. つまり、レガシーコード 10

  11. レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない 11

  12. レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない → 開発速度の鈍化 12

  13. レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない → 開発速度の鈍化 → サービスの成長が鈍化している 13

  14. もう少し課題の原因を深堀りする 14

  15. 開発速度の鈍化の原因 • レガシーコードであること 15

  16. 開発速度の鈍化の原因 • レガシーコードであること • 1度のリリースのコードの変更量が多い ◦ コードレビューや UI テスト(人力)のコストが増加 •

    ↑2つが合わさってバグが生まれやすくなり、さらに 開発工数がかさむ 16
  17. 1度のリリースの変更量を減らしたい 17

  18. 1度のリリースの変更量を減らしたい →フィーチャートグルという戦略 18

  19. その他、背景 • エンジニア以外の人でも、リリース前に変更内容を 確認できるようにしたい ◦ 他部署の人が変更内容を事前にキャッチアップできる ように ◦ 開発担当者以外が確認する事で、未然にバグを発見で きるように

    19
  20. 導入背景をまとめると • 1度のリリースの変更量を減らしたい • エンジニア以外の人でも、リリース前に変更内容を 確認できるようにしたい 20

  21. フィーチャートグルを導入した結果 21

  22. 2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 22

  23. 2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 23

  24. 2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 24

  25. 「細かい変更を頻繁に」行う用になった理由 • 細かい変更を頻繁に行える仕組みがある ◦ =フィーチャートグルが運用されている • デプロイ速度の改善 • UIテストの自動化ツールの導入 •

    フロントエンドのリプレイス • PHPコードのレガシー改善 • etc... 25
  26. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 26
  27. フィーチャートグルとは何か • コードを書き換えることなく動的にシステムの振る 舞いを変更できる開発手法 • アプリの再起動やコードのデプロイを伴わない 参考: https://martinfowler.com/articles/feature-toggles.html 27

  28. フィーチャートグルの例 参考: https://martinfowler.com/articles/feature-toggles.html 28

  29. フィーチャートグルの分類 • Release Toggles • Experiment Toggles • Ops Toggles

    • Permission Toggles 29
  30. フィーチャートグルの分類 • Release Toggles • Experiment Toggles • Ops Toggles

    • Permission Toggles PR TIMES が使っているものは Release Toggles + α 30
  31. • トランクベース開発に利用されるフラグ ◦ 細かい変更を頻繁に main ブランチにマージする手法 • 開発中の機能をOFFにすることで、機能が未完成で あっても main

    ブランチにマージできる • このフラグは静的である Release Toggles 31
  32. • トランクベース開発に利用されるフラグ ◦ 細かい変更を頻繁に main ブランチにマージする手法 • 開発中の機能をOFFにすることで、機能が未完成で あっても main

    ブランチにマージできる • このフラグは静的である ただし、社内からのアクセスだけ、動的にフラグを切り 替える事が出来て、開発中の機能を試す事ができる PR TIMES が使っている Release Toggles 32
  33. PR TIMES が使っている Release Toggles 33

  34. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 34
  35. フィーチャートグルの導入方針 • 必要最低限の機能で実装する • 導入することに比重をおく ◦ レガシーコードは一旦無視 ◦ 導入後にリファクタリングする 35

  36. 仕様の確認 36

  37. フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 37

  38. 実装 38

  39. フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 39

  40. 実装切り替えのコード 40

  41. フラグは常にOFFにする 41

  42. フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 42

  43. 実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 43

  44. フィーチャートグルの実装方針 44

  45. フィーチャートグルの実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 45

  46. (オフィス・VPNの)IPアドレスから判定 46

  47. (オフィス・VPNの)IPアドレスから判定 47

  48. (オフィス・VPNの)IPアドレスから判定 48

  49. (オフィス・VPNの)IPアドレスから判定 49

  50. フィーチャートグルの実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 50

  51. Cookiesでフラグを管理 51

  52. Cookiesでフラグを管理 52

  53. Cookiesでフラグを管理 53

  54. 導入完了 54

  55. なんでスーパーグローバル を使っているの? 55

  56. その裏側は?(去年まで) • PHP x.x ( < 8.1 ) で動いている •

    触れるとすべてが崩壊する独自フレームワーク • テストなし • Namespaceなし • スーパーグローバル使いたい放題 56
  57. 正しい設計・実装 を行うこと フィーチャートグル を導入すること < 57

  58. 第一優先でフィーチャートグルを導入する • この実装でレガシーコードが増える事は承知の上 ◦ 既にレガシーコードだから、レガシーコードが増えて も良い、というわけではない ◦ 導入後、開発速度を上がった時にリファクタリングす れば良いという考え ※これは、会社・個人によって方針は変わると思います。

    58
  59. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 59
  60. フィーチャートグルを使ってもらう 60

  61. フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 61

  62. フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 62

  63. 1度のリリースの変更量を減らす • チケットの粒度を小さくする ◦ 実装開始から1〜2日で終わる程度に • 細かい変更量で main ブランチにマージする ◦

    Release Toggles を OFF にすることで、開発中の 機能であっても影響なくマージ可能 • 「細かい変更を頻繁に」という意識を持つ 63
  64. 「細かい変更を頻繁に」という意識を持つ • チケット(Issue or Pull Request)の粒度自体にも アドバイスをする 64

  65. フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 65

  66. 現在の実装のコードを確認 66

  67. • Namespaceを用意していないので Autoloader が 使えない • Featureテストでスーパーグローバルを操作出来ない ので、ONの時の動作をテスト出来ない ◦ (または、テスト自体できない)

    現在の実装の問題点 67
  68. リファクタリングをする 68

  69. • クラス化(Namespaceが設定された状態) ◦ 動的にフラグの切り替えもできるようにする • スーパーグローバルをインジェクトできるようにす る リファクタリングをする 69

  70. クラス化(Namespaceが設定された状態) 70

  71. 動的にフラグの切り替えもできるようにする 71

  72. 少しコードをきれいに 72

  73. 少しコードをきれいに 73

  74. スーパーグローバルをインジェクトできるよ うにする 74

  75. スーパーグローバルをインジェクトできるよ うにする 75

  76. スーパーグローバルをインジェクトできるよ うにする 76

  77. フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 77

  78. 社内で共有する 78

  79. • エンジニアは、フィー チャートグルを用いた開発 が行えるように • エンジニア以外は、フィー チャートグルの切り替え方 法がわかるように 社内Wikiで共有 79

  80. • 社内で多くの人に使っ てもらう Slackで共有 「プレスキット」という機能がリリースされる数日前の様子 80

  81. 社外で共有する 81

  82. • 社内外の人に認知しても らう ◦ 社内の人にとっても 参考資料となる ◦ 新しくJOINする人に 事前に知ることができ る情報となる

    テックブログで発信 82
  83. アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •

    まとめ 83
  84. • レガシーコードだからこそ、必要最低限の質素な実 装でフィーチャートグルを導入する • その後にテスタブルにする、リファクタリングする • 結果、開発速度が向上しました まとめ 84

  85. • フィーチャーフラグにはタイプ(リリース・実験・運用・許可)がある! ◦ https://kakakakakku.hatenablog.com/entry/2022/02/01/102104 • 小さく安全なリリースを実現するために使える「フィーチャートグル」って 何?年収は?彼女は?調べてみました! ◦ https://qiita.com/ipeblb/items/92b794321751a6fa133e •

    FeatureToggle戦略と運用方法 ◦ https://speakerdeck.com/kubotak/featuretogglezhan-lue-toyun-yong-fang-fa • トランク ベース開発 ◦ https://www.atlassian.com/ja/continuous-delivery/continuous-integration/trun k-based-development 参考 85
  86. • 株式会社PR TIMESはPHPer募集しています ◦ https://herp.careers/v1/prtimes/ePCFEMomxCoA • テックブログもやっているので是非見てください ◦ https://developers.prtimes.jp/ 会社紹介

    86