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
Flutterアプリで可用性を向上させたFeatureFlagの運用戦略とその方法
Search
Kakeru Nakabachi
November 21, 2024
0
400
Flutterアプリで可用性を向上させたFeatureFlagの運用戦略とその方法
Kakeru Nakabachi
November 21, 2024
Tweet
Share
More Decks by Kakeru Nakabachi
See All by Kakeru Nakabachi
Inside Flutter Text
b4tchkn
1
130
Flutterアプリのセキュリティ対策を考えてみる
b4tchkn
5
5.2k
Textの構造を理解する/Understanding the Structure of Text
b4tchkn
3
2k
チームで採用しているriverpodを使ったFlutterのアーキテクチャとriverpod v1.0.0
b4tchkn
6
4.5k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
95
5.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Unsuck your backbone
ammeep
669
57k
Building Your Own Lightsaber
phodgson
103
6.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
A Modern Web Designer's Workflow
chriscoyier
693
190k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Visualization
eitanlees
146
15k
Transcript
Flutterアプリで 可用性を向上させた FeatureFlagの運用戦略とその方法 FlutterKaigi 2024 batch / Kakeru
Nakabachi
株式会社WinTicket Mobile Application Engineer 中鉢 かける Kakeru Nakabachi @b4tchkn @b4tchkn
過去の登壇 https://speakerdeck.com/b4tchkn/understanding-the-structure-of-text https://speakerdeck.com/b4tchkn/flutterapurinosekiyuriteidui-ce-wokao-etemiru
WINTICKETとは
Flutterリプレイス後の FeatureFlag運用 従来のFeatureFlagを使用した開発 発生した不具合の分析と整理 可用性向上のための運用戦略とその方法 01 02 03 04 CONTENTS
対応した結果と今後の展望 05
01 Flutterリプレイス後の FeatureFlag運用と課題
プロジェクトスタート時からトランクベース開発を採用 運用での新機能開発はFeatureFlagを使用してトランクベース開発 Flutterリプレイス後のFeatureFlag運用 WINTICKETアプリのFlutterリプレイス 01 2021/03 現在 2022/04 2023/03 Flutterリプレイススタート
Androidアプリをリプレイス iOSアプリをリプレイス
Flutterリプレイス後のFeatureFlag運用 WINTICKETアプリのFlutterリプレイス 01 https://developers.cyberagent.co.jp/blog/archives/36144/ https://developers.cyberagent.co.jp/blog/archives/41543/
機能追加や改修のようなコード差分を小さな単位に分割してmainブランチ(ト ランク)にマージしていくバージョン管理手法 機能が完成しているか関わらず、常に修正がmainにマージされてリリースされ る https://dora.dev/capabilities/trunk-based-development/ Flutterリプレイス後のFeatureFlag運用 トランクベース開発とは 01 main(trunk) Release
1.0 Release 1.1 branch-A branch-B
Flutterリプレイス後のFeatureFlag運用 FeatureFlagとは 静的または動的に機能のON/OFFを切り替える手法 トランクベース開発で未完成の機能をリリースに含めるが、実行されないよう に隠すためにFeatureFlagを使用する https://martinfowler.com/articles/feature-toggles.html 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlagを使ったトランクベース開発 01 main(trunk) Release 1.0 Release 1.1 branch-A branch-B
未完成の機能実装 FeatureFlag OFF 🚩FeatureFlag ON 機能の完成
Flutterリプレイス後のFeatureFlag運用 前提知識1/2:アプリチームの開発状況 • FeatureFlagを使ったトランクベース開発をリプレイスプロジェクト開始時 から3年以上運用 • 運用フェーズ後の新機能追加時はFeatureFlagを使用して機能を閉じな がらアプリを毎週リリース • 常に20個弱のFeatureFlagをプロジェクトコードに埋め込みながら2~3機
能を同時並行開発 • 新卒を積極的に配属して既存コードの理解が浅いメンバーの急増 01
Flutterリプレイス後のFeatureFlag運用 前提知識2/2:アプリのレイヤー構成 • Clean Architectureに寄せたData、 Domain、State、UIのレイヤーで構 成 • RiverpodでDIと状態管理 01
Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service UI State Domain Data
Flutterリプレイス後のFeatureFlag運用 前提知識2/2:アプリのレイヤー構成 Domain 01 Connected Screen Stateless Screen Widget Selector
State UseCase Persistence Service UI State Domain Data
Flutterリプレイス後のFeatureFlag運用 前提知識2/2:アプリのレイヤー構成 State 01 Connected Screen Stateless Screen Widget Selector
State UseCase Persistence Service UI State Domain Data
Flutterリプレイス後のFeatureFlag運用 前提知識2/2:アプリのレイヤー構成 UI Stateの参照はConnected Screenでの み行う Connected ScreenでStateを束ねる Stateless ScreenはConnected
Screen から値を受け取り、直接Stateの参照はし ない 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service UI State Domain Data
Flutterリプレイス後のFeatureFlag運用 前提知識2/2:アプリのレイヤー構成 https://developers.cyberagent.co.jp/blog/archives/36149 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlagの使用用途 • 開発中の機能を細かいPRに分けてトランクにマージしてPRのリードタイ ムを短縮したい • コンフリクトを発生しにくくしたい • リリース時に不具合があったときに切り戻したい ➢
新機能開発、大規模なリファクタリング • 機能の効果検証をしたい ➢ 新機能開発の ABテスト 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 内製のFeatureFlagクライアントを使用 2つのタイプの実装 • workInProgress ◦ SharedPreferencesでいつでも手元でFeatureFlagの切り替えが可能 ◦ 開発中に使用
• ops ◦ Firebase RemoteConfigでリリース無しでFeatureFlagの切り替えが可能 ◦ 機能リリース時に使用 01
Flutterリプレイス後のFeatureFlag運用 Feature Toggles (aka Feature Flags) https://martinfowler.com/articles/feature-toggles.html 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlagのカテゴリ分類 • どれくらい切り替わる頻度が多い か? • どれくらい生存期間が長いか? Feature Toggles (aka
Feature Flags) 01 https://martinfowler.com/articles/feature-toggles.html
Flutterリプレイス後のFeatureFlag運用 WINTICKETでの利用カテゴリ 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 内製のFeatureFlagクライアントを使用 2つのタイプの実装 • workInProgress ◦ SharedPreferencesでいつでも手元でFeatureFlagの切り替えが可能 ◦ 開発中に使用
• ops ◦ Firebase RemoteConfigでリリース無しでFeatureFlagの切り替えが可能 ◦ 機能リリース時に使用 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 基本的なフラグ制御方法 • FeatureFlagClient.get() 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 UIでのフラグ制御方法① • useFlag UI(build関数)内で実行する ロジックを制御 ボタン押下処理・hooks内の 処理など 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 useFlagの実装↓ 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 UIでのフラグ制御方法② • FlagBuilder Widgetの出し分けを制御 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 FlagBuilderの実装↓ 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 画面遷移時のフラグ制御方法 • FlagGuard AutoRouteのRouteGuards機能を使用し た自前実装のGuardを用意 画面遷移時に画面遷移を許可するかの ロジックを実装できる DeepLinkでの遷移も防げる
01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag実装 FlagGuardの実装↓ 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01
Flutterリプレイス後のFeatureFlag運用 FeatureFlag導入原則 できるだけデータフローの根源で絶つ 01 Connected Screen Stateless Screen Widget Selector
State UseCase Persistence Service UI State Domain Data
Domain Flutterリプレイス後のFeatureFlag運用 FeatureFlag導入原則 できるだけデータフローの根源で絶つ • サーバーAPIの変更があったときは UseCaseでFeatureFlag制御 01 Connected Screen
Stateless Screen Widget Selector State UseCase Persistence Service 🚩 GET v1→v2 UI State Data
Flutterリプレイス後のFeatureFlag運用 FeatureFlag導入原則 できるだけデータフローの根源で絶つ • UIの変更があったときはUIで FeatureFlag制御 01 Connected Screen Stateless
Screen Widget Selector State UseCase Persistence Service 🚩 Button Red→Blue UI State Domain Data
02 従来のFeatureFlagを使用した開発
従来のFeatureFlagを使用した開発 従来の開発フロー 02 設計 実装 動作確認 QC リリース flag削除
従来のFeatureFlagを使用した開発 従来の開発フロー • 実装方針レビューを30分MTGで実施 • 記載内容 ◦ 実装概要 ◦
具体的な実装手順 ◦ 過去起きた不具合の考慮チェック 02 設計 実装 動作確認 QC リリース flag削除
従来のFeatureFlagを使用した開発 従来の開発フロー workInProgressのタイプでFeatureFlagの追加 実装要件に沿ってFeatureFlagClientを使用して実装 E2Eテストで基本FeatureFlagがOFFのテストをCIで実施 02 設計 実装 動作確認
QC リリース flag削除 https://developers.cyberagent.co.jp/blog/archives/41308/
従来のFeatureFlagを使用した開発 従来の開発フロー 機能開発チームやアプリチームで動作確認 • 仕様通りにメインの機能が動くかどうか手動テスト • FeatureFlag EditorでFeatureFlagを手動でONに 変更して検証
02 設計 実装 動作確認 QC リリース flag削除
従来のFeatureFlagを使用した開発 従来の開発フロー QCチームへ手動テストを依頼 ONに切り替えてほしいFeatureFlagの共有をしてテストを実施 02 設計 実装 動作確認 QC
リリース flag削除 フラグ名
従来のFeatureFlagを使用した開発 従来の開発フロー FeatureFlagをopsに変更して申請 ビジネスメンバーとリリースタイミングをすり合わせてリリース FeatureFlagはFirebase RemoteConfigを操作 02 設計 実装
動作確認 QC リリース flag削除
従来のFeatureFlagを使用した開発 従来の開発フロー 月1でSlackのWorkflowでリマインド リリースして約1ヶ月経過していて、機能 が安定しているFeatureFlagは削除 02 設計 実装 動作確認
QC リリース flag削除
03 発生した不具合の分析と整理
従来のFeatureFlagを使用した開発 よくある実装要件 UI • 新機能追加 ◦ 投票履歴画面を新しく追加 • 既存機能の改修
◦ トップ画面を新デザインにリニューアルしたい 02
従来のFeatureFlagを使用した開発 よくある実装要件 Domain • 新機能追加 ◦ トップで情報を表示するために新規でサーバー APIリクエストしたい •
既存機能の改修 ◦ サーバーAPIのリクエストをv1からv2にしたい 02
発生した不具合の分析と整理 実際の不具合発生ケース 発生ケースパターン 03 Domain UI 不具合発生頻度 新規追加 新規追加
低 既存改修 新規追加 低 新規追加 既存改修 中 既存改修 既存改修 高 発生しやすいケース
発生した不具合の分析と整理 実際の不具合発生ケース 発生ケースパターン 03 Domain UI 不具合発生頻度 新規追加 新規追加
低 既存改修 新規追加 低 新規追加 既存改修 中 既存改修 既存改修 高 発生しやすいケース
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ②:①がきたらDomain呼び出し
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読
②:Domain呼び出し
発生した不具合の分析と整理 実際の不具合発生ケース 03 UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読 ②:Domain呼び出し
既存のデータフローを削除して 実 質同じ挙動 になるように変更 Domain UI
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読
②:Domain呼び出し 購読のやりかたにミス ④が実行されない UI
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読
②:Domain呼び出し 購読のやりかたにミス ④が実行されない 不具合発生 🚨 UI
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読
②:Domain呼び出し 既存のデータフローも無いので 切り戻しできない UI
発生した不具合の分析と整理 実際の不具合発生ケース 03 Domain UI ①:イベント購読 ④:③がきたらDomain呼び出し Domain ③:イベント購読
②:Domain呼び出し 理想は既存には手を触れずに改修 どちらのデータフローも実行で きるようにフラグ分岐 🚩 UI
発生した不具合の分析と整理 実際の不具合発生ケース 発生ケースパターン 03 Domain UI 不具合発生頻度 新規追加 新規追加
低 既存改修 新規追加 低 新規追加 既存改修 中 既存改修 既存改修 高 発生しやすいケース
発生した不具合の分析と整理 実際の不具合発生ケース UI既存改修での不具合 • hooks、Providerのlistenのコールバック内での分岐漏れ • FlagBuilderのbuilder内での分岐漏れ 03
発生した不具合の分析と整理 実際の不具合発生ケース Route追加での不具合 • FlagGuardを追加していたがmetaの設定忘れ 03
発生した不具合の分析と整理 実際の不具合発生ケース Domain新規追加での不具合 • 新規Domain追加時にFeatureFlagの制御の入れ忘れ • 新規Domainを既存画面からアクセスされたときに実行しないようにする 対応漏れ 03
発生した不具合の分析と整理 実際の不具合発生ケース まとめ • 既存改修が複数レイヤーで起こると 不具合が発生しやすい • 既存は変更をしないように改修した い
03 Domain UI 不具合発生頻度 新規追加 新規追加 低 既存改修 新規追加 低 新規追加 既存改修 中 既存改修 既存改修 高
発生した不具合の分析と整理 課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようする 03
発生した不具合の分析と整理 課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようする 既存改修するときは、既存の実装には触れずそのままの実装をFeatureFlag で切り戻せるようにする たとえ実質挙動が一緒にできても、既存実装は手を加えない
03
発生した不具合の分析と整理 課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようにしたい 実装者もレビュー者も人間なので忘れてしまうときはある できるだけ人間が直接関与しないようにする 03
発生した不具合の分析と整理 コードベース以外の考慮 • 若手が多いチーム構成 • 組織拡大時期で人の流動性が高い • 他の横軸並行タスクが多く、ヒューマンエラーが起こりやすい 中堅メンバーの能力に頼らず、いつでも誰でも安全に
FeatureFlag制御でき るような実装制限をかけたい 03
発生した不具合の分析と整理 解決したいことの整理 • アプローチ ◦ 既存は触れずに残しながら改修できるようにする ◦ 制御忘れに機械的に気付けるようする ➢
若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限 をかけたい 03
04 可用性向上のための運用戦略とその方法
可用性向上のための運用戦略とその方法 運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04
可用性向上のための運用戦略とその方法 運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04
可用性向上のための運用戦略とその方法 実際の不具合から考える運用戦略 • 既存は触れずに残しながら改修できるようにする • 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限 をかけたい • 制御忘れに機械的に気付けるようする
シンプルな真偽値(bool)制御を禁止して、既存の実装には全く手をつけない実 装制限をかける 04
可用性向上のための運用戦略とその方法 実際の不具合から考える運用戦略 • 既存は触れずに残しながら改修できるようにする • 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限 をかけたい • 制御忘れに機械的に気付けるようする
レビュー時に機械的に気付けるように 04
可用性向上のための運用戦略とその方法 実際の不具合から考える運用戦略 1. 既存の実装には全く手をつけない実装制限をかける 2. 機械的に気付けるようにする 04
可用性向上のための運用戦略とその方法 実際の不具合から考える運用戦略 1. 既存の実装には全く手をつけない実装制限をかける 2. 機械的に気付けるようにする 04
可用性向上のための運用戦略とその方法 実際の不具合から考える運用戦略 実装制限のかけかた • 制御レイヤーの制限 • 分岐制御の制限 04
可用性向上のための運用戦略とその方法 運用戦略 - 制御レイヤーの制限 できるだけデータフローの根本のDomainだけで分岐が完結できると、UIと Domainでのデータフローでミスが起こりにくくなる 04 UI State
Domain Data Source ON:文字列 OFF:空文字 UIは文字列があるかど うかで表示を制御 FeatureFlagは意識しな い データフロー 🛠FeatureFlag分岐
可用性向上のための運用戦略とその方法 運用戦略 - 制御レイヤーの制限 理想は制御レイヤーをDomainだけに絞りたい Domainだけで制御できるように実装者が設計することで、デグレしにくい制御 ができるようにする 04 UI
State Domain Data Source
可用性向上のための運用戦略とその方法 運用戦略 - 制御レイヤーの制限 UIのみの改修の場合はUIでしかFeatureFlag分岐はできない • 例 ◦ ボタンの文言の切り替えで
ABテストしたい ◦ ボタン押下したときの遷移先を変更したい 04 UI State Domain Data Source
可用性向上のための運用戦略とその方法 運用戦略 - 制御レイヤーの制限 従来通り、制御レイヤーは基本 UI・Domainレイヤーのみにする これ以外の特殊な例外は一部Stateも 許容する 04
Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service 🚩 🚩 UI State Domain Data
可用性向上のための運用戦略とその方法 運用戦略 - 分岐制御の制限 • FeatureFlagをbool値で扱うと自由度が高すぎて簡単に複雑なロジック制 御が可能になる • 既存のif文に組み合わせたり、三項演算子に混ぜたり
Domainでは不具合が発生した例はなかったのでUIのみ制限をかける 04
可用性向上のための運用戦略とその方法 運用戦略 - 分岐制御の制限 UIではシンプルなboolでFeatureFlagを取り出せないようにして、ONとOFFの 処理を明示的に分けるインターフェースでしかフラグ分岐できないようにする 04 Before After
可用性向上のための運用戦略とその方法 運用戦略 - 分岐制御の制限 分岐制御の制限によって、既存の実装はコピペで残して触れずに避ける 04 改修後 改修前
可用性向上のための運用戦略とその方法 運用戦略 - 分岐制御の制限 04
可用性向上のための運用戦略とその方法 運用戦略 - 分岐制御の制限 04 変更はここのみ この辺は冗長だが、可 用性を重視
可用性向上のための運用戦略とその方法 運用戦略 1. 既存の実装には全く手をつけない実装制限をかける 2. 制御忘れに機械的に気付けるようする 04
可用性向上のための運用戦略とその方法 運用戦略 - できるだけ機械に任せたい 1. 新規ページ追加時FlagGuardの設定忘れ FlagGuardがないときにPull Request上でDangerでwarning 04
可用性向上のための運用戦略とその方法 運用戦略 - できるだけ機械に任せたい Danger CIプロセス中に実行できて、一般的なコードレビュー作業を自動化するツール https://danger.systems/ruby/ 04
可用性向上のための運用戦略とその方法 運用戦略 - できるだけ機械に任せたい 2. UseCase追加時にFeatureFlag制御がない 新規追加時Dangerで警告 04
可用性向上のための運用戦略とその方法 運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04
可用性向上のための運用戦略とその方法 開発フローで見る戦略 • 実装方針レビューでFeatureFlagについてレビューできるように 04 設計 実装 動作確認 QC
リリース flag削除 追加
可用性向上のための運用戦略とその方法 開発フローから見る戦略 04 設計 実装 動作確認 QC リリース flag削除
レビュー方法 ドキュメント作成 BEFORE 30分MTGでレビュー ドキュメント管理ツール AFTER PullRequest上でコードレビューと同 じ方法でレビュー PullRequest(MarkDown)
可用性向上のための運用戦略とその方法 開発フローから見る戦略 • FeatureFlagがONのときとOFFのときでE2EシナリオをCIで実行 • 既にopsのFeatureFlagを誤って参照したときにDangerで警告 04 設計 実装
動作確認 QC リリース flag削除 フラグ名
可用性向上のための運用戦略とその方法 開発フローから見る戦略 • workInProgressからopsに切替時に誤ったFeatureFlagを参照している 箇所がないかを確認できるように 04 設計 実装 動作確認
QC リリース flag削除 フラグ名
可用性向上のための運用戦略とその方法 検討して採用しなかったこと 04 • 課題に対する大きな変更 ◦ Gitflowな開発 ◦ プロジェクトコード全体のリアーキテクチャ
◦ 理想形の追求 • 課題が起きていない箇所への変更 • FeatureFlagの利用方針 ◦ UIに近いところで分岐
05 対応した結果と今後の展望
対応した結果と今後の展望 可用性と利便性のトレードオフ 05 可用性 高 利便性 高 利便性 低
可用性 低 理 想 現 実
対応した結果と今後の展望 メリット 1. FeatureFlagによる制御漏れのミスはゼロに 2. いい意味で自由度がなくなり、実装時に誰でもFeatureFlag設計を考えら れるように 05
対応した結果 デメリット 04 1. シンプルなboolの制御がないと厳しい場面がある 2. 可用性を考えるよりも冗長さが勝るときがある 3. Lintや設計のような強い制限ではないので新メンバーが迷う
対応した結果 デメリット 1. シンプルなboolの制御がないと厳しい場面がある UIから参照しているメソッドの中の一部を分岐したいとき UIからboolを渡してメソッド内で分岐したい 04
対応した結果 デメリット 04 2. 可用性を考えるよりも冗長さが勝るときがある Widgetのbuild()内で参照している他のメソッドの中身を別なロジックにに分岐 したい ref.listen()してる中の処理を分岐したい
対応した結果 デメリット 04 3. Lintや設計のような強い制限ではないので新メンバーが迷う Pull Requestで初めて「そういう決まりあったんだ」になることが多々ある ドキュメントは古くなりやすく、読まれづらい
対応した結果と今後の展望 今後の展望 可用性以外の利便性の向上 • 自動でRemoteConfigに追加 • RemoteConfigでFeatureFlagが変更されたら通知 • 可用性を考慮した迷いがないFeatureFlag実装
• ABテスト設定の自動化 • DangerからCustomLintへの置き換え 05
ご清聴ありがとうございます
参考 参考 • https://dora.dev/capabilities/trunk-based-development/ • https://martinfowler.com/articles/feature-toggles.html • https://cadc.cyberagent.co.jp/2023/sessions/winticket-flutter-app/ • https://developers.cyberagent.co.jp/blog/archives/36149/
• https://danger.systems/ruby/