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.4k
ローンチから16年目のWebサービスに、どうやってフィーチャートグルを導入したか、運用しているか / phpcon2022
phpcon-2022
---
内容
- 弊社サービスにおけるフィーチャートグルを導入した効果
- フィーチャートグルの導入〜現在に至るまでの実装
- 導入後にテストを可能にするための改善
meihei
September 24, 2022
Tweet
Share
More Decks by meihei
See All by meihei
WebアプリケーションにおけるPDOの使い方入門 / phpcon odawara 2024
meihei3
3
1k
PHPerライフをChrome拡張開発でちょっと便利に / PR TIMES x DMM.com
meihei3
0
320
ファイルを選択してZIPダウンロードする機能ってどうやって作るの? / phpcondo 2023
meihei3
1
490
New Relic CodeStreamを 使って、エラーを 加速的迅速に改修しよう! #NRUG Vol.8
meihei3
0
240
PHP8.2から見る、2つの配列 / PHP Conference Japan 2023
meihei3
0
1.8k
良いコードを書く 〜10年後のPR TIMESを作る〜 / LT会 in #PRTIMES_HACKATHON 2023
meihei3
1
190
月に一度の大規模リファクタリングでレガシーコードと向き合う取り組み / PHP Conference Fukuoka 2023
meihei3
3
1k
PHPの配列とデータ構造 / PHPerKaigi 2023
meihei3
2
1.7k
PHPerKaigi 2022 スタッフとして参加した
meihei3
0
510
Other Decks in Programming
See All in Programming
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
610
役立つログに取り組もう
irof
28
9.6k
Jakarta EE meets AI
ivargrimstad
0
670
[Do iOS '24] Ship your app on a Friday...and enjoy your weekend!
polpielladev
0
110
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
690
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
9
3.3k
Outline View in SwiftUI
1024jp
1
330
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
suzukihoge
14
2.2k
OnlineTestConf: Test Automation Friend or Foe
maaretp
0
110
ヤプリ新卒SREの オンボーディング
masaki12
0
130
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
Featured
See All Featured
KATA
mclloyd
29
14k
Adopting Sorbet at Scale
ufuk
73
9.1k
Scaling GitHub
holman
458
140k
What's in a price? How to price your products and services
michaelherold
243
12k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Designing for Performance
lara
604
68k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
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