Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ローンチから16年目のWebサービスに、どうやってフィーチャートグルを導入したか、運用している...
Search
meihei
September 24, 2022
Programming
2
3.8k
ローンチから16年目のWebサービスに、どうやってフィーチャートグルを導入したか、運用しているか / phpcon2022
phpcon-2022
---
内容
- 弊社サービスにおけるフィーチャートグルを導入した効果
- フィーチャートグルの導入〜現在に至るまでの実装
- 導入後にテストを可能にするための改善
meihei
September 24, 2022
Tweet
Share
More Decks by meihei
See All by meihei
List とは何か? / PHPerKaigi 2025
meihei3
0
520
WebアプリケーションにおけるPDOの使い方入門 / phpcon odawara 2024
meihei3
3
1.7k
PHPerライフをChrome拡張開発でちょっと便利に / PR TIMES x DMM.com
meihei3
0
360
ファイルを選択してZIPダウンロードする機能ってどうやって作るの? / phpcondo 2023
meihei3
1
590
New Relic CodeStreamを 使って、エラーを 加速的迅速に改修しよう! #NRUG Vol.8
meihei3
0
310
PHP8.2から見る、2つの配列 / PHP Conference Japan 2023
meihei3
0
2k
良いコードを書く 〜10年後のPR TIMESを作る〜 / LT会 in #PRTIMES_HACKATHON 2023
meihei3
1
220
月に一度の大規模リファクタリングでレガシーコードと向き合う取り組み / PHP Conference Fukuoka 2023
meihei3
3
1.1k
PHPの配列とデータ構造 / PHPerKaigi 2023
meihei3
2
1.9k
Other Decks in Programming
See All in Programming
AIエージェントを活用したアプリ開発手法の模索
kumamotone
1
740
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
自分のために作ったアプリが、グローバルに使われるまで / Indie App Development Lunch LT
pixyzehn
1
120
AtCoder Heuristic First-step Vol.1 講義スライド(山登り法・焼きなまし法編)
takumi152
3
960
複数ドメインに散らばってしまった画像…! 運用中のPHPアプリに後からCDNを導入する…!
suguruooki
0
430
NestJSのコードからOpenAPIを自動生成する際の最適解を探す
astatsuya
0
180
JavaOne 2025: Advancing Java Profiling
jbachorik
1
310
RCPと宣言型ポリシーについてのお話し
kokitamura
2
140
データベースエンジニアの仕事を楽にする。PgAssistantの紹介
nnaka2992
9
4.1k
いまさら聞けない生成AI入門: 「生成AIを高速キャッチアップ」
soh9834
12
3.6k
バックエンドNode.js × フロントエンドDeno で開発して得られた知見
ayame113
5
1.3k
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
590
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.7k
Six Lessons from altMBA
skipperchong
27
3.7k
Being A Developer After 40
akosma
90
590k
Thoughts on Productivity
jonyablonski
69
4.5k
Bash Introduction
62gerente
611
210k
Documentation Writing (for coders)
carmenintech
69
4.7k
Designing for Performance
lara
605
69k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Designing Experiences People Love
moore
140
23k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Transcript
ローンチから16年目の Webサービスに、 どうやってフィーチャートグル を導入したか、 運用しているか。
自己紹介 名前: meihei(江間洋平) 所属: 株式会社PR TIMES Twitter: app1e_s GitHub: meihei3
VTuberの配信を流して生きて います 2
今回が初登壇です🙌 3
この発表の位置づけ 4
5 ローンチから16年目の Webサービスに、 どうやってフィーチャートグル を導入したか、 運用しているか。
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 6
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 7
PR TIMESというサービスについて • プレスリリース配信サービス • 月間のサイト閲覧数 は6,000万PV 8
その裏側は?(去年まで) • PHP x.x ( < 8.1 ) で動いている •
触れるとすべてが崩壊する独自フレームワーク • テストなし • Namespaceなし • スーパーグローバル使いたい放題 9
つまり、レガシーコード 10
レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない 11
レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない → 開発速度の鈍化 12
レガシーコードゆえの課題 • コードを変更する事のコストが大きい • 少しの改修も一苦労 • 新規機能追加はなかなか行えない → 開発速度の鈍化 → サービスの成長が鈍化している 13
もう少し課題の原因を深堀りする 14
開発速度の鈍化の原因 • レガシーコードであること 15
開発速度の鈍化の原因 • レガシーコードであること • 1度のリリースのコードの変更量が多い ◦ コードレビューや UI テスト(人力)のコストが増加 •
↑2つが合わさってバグが生まれやすくなり、さらに 開発工数がかさむ 16
1度のリリースの変更量を減らしたい 17
1度のリリースの変更量を減らしたい →フィーチャートグルという戦略 18
その他、背景 • エンジニア以外の人でも、リリース前に変更内容を 確認できるようにしたい ◦ 他部署の人が変更内容を事前にキャッチアップできる ように ◦ 開発担当者以外が確認する事で、未然にバグを発見で きるように
19
導入背景をまとめると • 1度のリリースの変更量を減らしたい • エンジニア以外の人でも、リリース前に変更内容を 確認できるようにしたい 20
フィーチャートグルを導入した結果 21
2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 22
2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 23
2021年4月〜12月上旬までの開発生産性 • レガシーコードであること ※フィーチャートグル以外の要因もあります 24
「細かい変更を頻繁に」行う用になった理由 • 細かい変更を頻繁に行える仕組みがある ◦ =フィーチャートグルが運用されている • デプロイ速度の改善 • UIテストの自動化ツールの導入 •
フロントエンドのリプレイス • PHPコードのレガシー改善 • etc... 25
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 26
フィーチャートグルとは何か • コードを書き換えることなく動的にシステムの振る 舞いを変更できる開発手法 • アプリの再起動やコードのデプロイを伴わない 参考: https://martinfowler.com/articles/feature-toggles.html 27
フィーチャートグルの例 参考: https://martinfowler.com/articles/feature-toggles.html 28
フィーチャートグルの分類 • Release Toggles • Experiment Toggles • Ops Toggles
• Permission Toggles 29
フィーチャートグルの分類 • Release Toggles • Experiment Toggles • Ops Toggles
• Permission Toggles PR TIMES が使っているものは Release Toggles + α 30
• トランクベース開発に利用されるフラグ ◦ 細かい変更を頻繁に main ブランチにマージする手法 • 開発中の機能をOFFにすることで、機能が未完成で あっても main
ブランチにマージできる • このフラグは静的である Release Toggles 31
• トランクベース開発に利用されるフラグ ◦ 細かい変更を頻繁に main ブランチにマージする手法 • 開発中の機能をOFFにすることで、機能が未完成で あっても main
ブランチにマージできる • このフラグは静的である ただし、社内からのアクセスだけ、動的にフラグを切り 替える事が出来て、開発中の機能を試す事ができる PR TIMES が使っている Release Toggles 32
PR TIMES が使っている Release Toggles 33
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 34
フィーチャートグルの導入方針 • 必要最低限の機能で実装する • 導入することに比重をおく ◦ レガシーコードは一旦無視 ◦ 導入後にリファクタリングする 35
仕様の確認 36
フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 37
実装 38
フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 39
実装切り替えのコード 40
フラグは常にOFFにする 41
フィーチャートグルの仕様 • ON/OFF を切り替える事で、実装を切り替える • 基本的にリリース時まではフラグをOFFにする • ただし、社内からのアクセスだけは、動的にフラグ を切り替える事ができる 42
実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 43
フィーチャートグルの実装方針 44
フィーチャートグルの実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 45
(オフィス・VPNの)IPアドレスから判定 46
(オフィス・VPNの)IPアドレスから判定 47
(オフィス・VPNの)IPアドレスから判定 48
(オフィス・VPNの)IPアドレスから判定 49
フィーチャートグルの実装方針 • 社内からのアクセスを判定する事ができる ◦ (オフィス・VPNの)IPアドレスから判定 • 動的にフラグを切り替える事ができる ◦ Cookiesでフラグを管理 50
Cookiesでフラグを管理 51
Cookiesでフラグを管理 52
Cookiesでフラグを管理 53
導入完了 54
なんでスーパーグローバル を使っているの? 55
その裏側は?(去年まで) • PHP x.x ( < 8.1 ) で動いている •
触れるとすべてが崩壊する独自フレームワーク • テストなし • Namespaceなし • スーパーグローバル使いたい放題 56
正しい設計・実装 を行うこと フィーチャートグル を導入すること < 57
第一優先でフィーチャートグルを導入する • この実装でレガシーコードが増える事は承知の上 ◦ 既にレガシーコードだから、レガシーコードが増えて も良い、というわけではない ◦ 導入後、開発速度を上がった時にリファクタリングす れば良いという考え ※これは、会社・個人によって方針は変わると思います。
58
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 59
フィーチャートグルを使ってもらう 60
フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 61
フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 62
1度のリリースの変更量を減らす • チケットの粒度を小さくする ◦ 実装開始から1〜2日で終わる程度に • 細かい変更量で main ブランチにマージする ◦
Release Toggles を OFF にすることで、開発中の 機能であっても影響なくマージ可能 • 「細かい変更を頻繁に」という意識を持つ 63
「細かい変更を頻繁に」という意識を持つ • チケット(Issue or Pull Request)の粒度自体にも アドバイスをする 64
フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 65
現在の実装のコードを確認 66
• Namespaceを用意していないので Autoloader が 使えない • Featureテストでスーパーグローバルを操作出来ない ので、ONの時の動作をテスト出来ない ◦ (または、テスト自体できない)
現在の実装の問題点 67
リファクタリングをする 68
• クラス化(Namespaceが設定された状態) ◦ 動的にフラグの切り替えもできるようにする • スーパーグローバルをインジェクトできるようにす る リファクタリングをする 69
クラス化(Namespaceが設定された状態) 70
動的にフラグの切り替えもできるようにする 71
少しコードをきれいに 72
少しコードをきれいに 73
スーパーグローバルをインジェクトできるよ うにする 74
スーパーグローバルをインジェクトできるよ うにする 75
スーパーグローバルをインジェクトできるよ うにする 76
フィーチャートグルを使ってもらう為に • トランクベース開発を実践する • フィーチャートグル自体を使いやすい物にする • 情報を公開する 77
社内で共有する 78
• エンジニアは、フィー チャートグルを用いた開発 が行えるように • エンジニア以外は、フィー チャートグルの切り替え方 法がわかるように 社内Wikiで共有 79
• 社内で多くの人に使っ てもらう Slackで共有 「プレスキット」という機能がリリースされる数日前の様子 80
社外で共有する 81
• 社内外の人に認知しても らう ◦ 社内の人にとっても 参考資料となる ◦ 新しくJOINする人に 事前に知ることができ る情報となる
テックブログで発信 82
アジェンダ • 導入の背景と結果 • フィーチャートグルについて • フィーチャートグルの実装・導入 • フィーチャートグルの運用・改善 •
まとめ 83
• レガシーコードだからこそ、必要最低限の質素な実 装でフィーチャートグルを導入する • その後にテスタブルにする、リファクタリングする • 結果、開発速度が向上しました まとめ 84
• フィーチャーフラグにはタイプ(リリース・実験・運用・許可)がある! ◦ 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
• 株式会社PR TIMESはPHPer募集しています ◦ https://herp.careers/v1/prtimes/ePCFEMomxCoA • テックブログもやっているので是非見てください ◦ https://developers.prtimes.jp/ 会社紹介
86