Flutterアプリで可用性を向上させたFeatureFlagの運用戦略とその方法

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

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の使用用途 • 開発中の機能を細かいPRに分けてトランクにマージしてPRのリードタイムを短縮したい • コンフリクトを発生しにくくしたい • リリース時に不具合があったときに切り戻したい ➢
新機能開発、大規模なリファクタリング • 機能の効果検証をしたい ➢ 新機能開発の ABテスト 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導入原則できるだけデータフローの根源で絶つ 01 Connected Screen Stateless Screen Widget Selector

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 リリース ﬂag削除

従来のFeatureFlagを使用した開発   従来の開発フロー • 実装方針レビューを30分MTGで実施 • 記載内容 ◦ 実装概要 ◦
具体的な実装手順 ◦ 過去起きた不具合の考慮チェック 02 設計実装動作確認 QC リリース ﬂag削除

従来のFeatureFlagを使用した開発   従来の開発フロー workInProgressのタイプでFeatureFlagの追加実装要件に沿ってFeatureFlagClientを使用して実装 E2Eテストで基本FeatureFlagがOFFのテストをCIで実施 02 設計実装動作確認
QC リリース ﬂag削除 https://developers.cyberagent.co.jp/blog/archives/41308/

従来のFeatureFlagを使用した開発   従来の開発フロー機能開発チームやアプリチームで動作確認 • 仕様通りにメインの機能が動くかどうか手動テスト • FeatureFlag EditorでFeatureFlagを手動でONに変更して検証
02 設計実装動作確認 QC リリース ﬂag削除

従来のFeatureFlagを使用した開発   従来の開発フロー QCチームへ手動テストを依頼 ONに切り替えてほしいFeatureFlagの共有をしてテストを実施 02 設計実装動作確認 QC
リリース ﬂag削除フラグ名 

従来のFeatureFlagを使用した開発   従来の開発フロー FeatureFlagをopsに変更して申請ビジネスメンバーとリリースタイミングをすり合わせてリリース FeatureFlagはFirebase RemoteConfigを操作 02 設計実装
動作確認 QC リリース ﬂag削除

従来のFeatureFlagを使用した開発   従来の開発フロー月1でSlackのWorkflowでリマインドリリースして約1ヶ月経過していて、機能が安定しているFeatureFlagは削除 02 設計実装動作確認
QC リリース ﬂag削除

03 発生した不具合の分析と整理

従来のFeatureFlagを使用した開発   よくある実装要件 UI • 新機能追加 ◦ 投票履歴画面を新しく追加 • 既存機能の改修
◦ トップ画面を新デザインにリニューアルしたい 02

従来のFeatureFlagを使用した開発   よくある実装要件 Domain • 新機能追加 ◦ トップで情報を表示するために新規でサーバー APIリクエストしたい •
既存機能の改修 ◦ サーバーAPIのリクエストをv1からv2にしたい 02

発生した不具合の分析と整理   実際の不具合発生ケース発生ケースパターン 03 Domain UI 不具合発生頻度新規追加新規追加
低既存改修新規追加低新規追加既存改修中既存改修既存改修高発生しやすいケース 

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ②：①がきたらDomain呼び出し 

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読 
②：Domain呼び出し 

発生した不具合の分析と整理   実際の不具合発生ケース 03 UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読  ②：Domain呼び出し 
既存のデータフローを削除して実質同じ挙動になるように変更 Domain  UI 

②：Domain呼び出し  購読のやりかたにミス ④が実行されない 󰢃 UI 

②：Domain呼び出し  購読のやりかたにミス ④が実行されない 󰢃 不具合発生 🚨 UI 

②：Domain呼び出し  既存のデータフローも無いので切り戻しできない UI 

②：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

可用性向上のための運用戦略とその方法   実際の不具合から考える運用戦略 • 既存は触れずに残しながら改修できるようにする • 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限をかけたい • 制御忘れに機械的に気付けるようする
シンプルな真偽値(bool)制御を禁止して、既存の実装には全く手をつけない実装制限をかける 04

可用性向上のための運用戦略とその方法   実際の不具合から考える運用戦略 • 既存は触れずに残しながら改修できるようにする • 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限をかけたい • 制御忘れに機械的に気付けるようする
レビュー時に機械的に気付けるように 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
リリース ﬂag削除追加

可用性向上のための運用戦略とその方法   開発フローから見る戦略 04 設計  実装動作確認 QC リリース ﬂag削除
レビュー方法ドキュメント作成 BEFORE 30分MTGでレビュードキュメント管理ツール AFTER PullRequest上でコードレビューと同じ方法でレビュー PullRequest(MarkDown)

可用性向上のための運用戦略とその方法   開発フローから見る戦略 • FeatureFlagがONのときとOFFのときでE2EシナリオをCIで実行 • 既にopsのFeatureFlagを誤って参照したときにDangerで警告 04 設計実装
動作確認 QC リリース ﬂag削除フラグ名 

可用性向上のための運用戦略とその方法   開発フローから見る戦略 • workInProgressからopsに切替時に誤ったFeatureFlagを参照している箇所がないかを確認できるように 04 設計実装動作確認
QC リリース ﬂag削除フラグ名 

可用性向上のための運用戦略とその方法   検討して採用しなかったこと 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/

Flutterアプリで可用性を向上させたFeatureFlagの運用戦略とその方法

Flutterアプリで可用性を向上させたFeatureFlagの運用戦略とその方法

More Decks by Kakeru Nakabachi

Featured

Transcript