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

by Kakeru Nakabachi

Slide 1

Slide 1 text

Flutterアプリで  可用性を向上させた   FeatureFlagの運用戦略とその方法   FlutterKaigi 2024  batch / Kakeru Nakabachi 

Slide 2

Slide 2 text

株式会社WinTicket  Mobile Application Engineer  中鉢かける Kakeru Nakabachi  @b4tchkn  @b4tchkn 

Slide 3

Slide 3 text

過去の登壇   https://speakerdeck.com/b4tchkn/understanding-the-structure-of-text https://speakerdeck.com/b4tchkn/flutterapurinosekiyuriteidui-ce-wokao-etemiru

Slide 4

Slide 4 text

WINTICKETとは

Slide 5

Slide 5 text

Flutterリプレイス後の FeatureFlag運用従来のFeatureFlagを使用した開発発生した不具合の分析と整理可用性向上のための運用戦略とその方法 01 02 03 04 CONTENTS 対応した結果と今後の展望 05

Slide 6

Slide 6 text

01 Flutterリプレイス後の FeatureFlag運用と課題

Slide 7

Slide 7 text

プロジェクトスタート時からトランクベース開発を採用運用での新機能開発はFeatureFlagを使用してトランクベース開発 Flutterリプレイス後のFeatureFlag運用  WINTICKETアプリのFlutterリプレイス 01 2021/03 現在 2022/04 2023/03 Flutterリプレイススタート  Androidアプリをリプレイス  iOSアプリをリプレイス 

Slide 8

Slide 8 text

Flutterリプレイス後のFeatureFlag運用  WINTICKETアプリのFlutterリプレイス 01 https://developers.cyberagent.co.jp/blog/archives/36144/ https://developers.cyberagent.co.jp/blog/archives/41543/

Slide 9

Slide 9 text

機能追加や改修のようなコード差分を小さな単位に分割してmainブランチ（トランク）にマージしていくバージョン管理手法機能が完成しているか関わらず、常に修正がmainにマージされてリリースされる https://dora.dev/capabilities/trunk-based-development/ Flutterリプレイス後のFeatureFlag運用  トランクベース開発とは 01 main(trunk) Release 1.0 Release 1.1 branch-A branch-B

Slide 10

Slide 10 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlagとは静的または動的に機能のON/OFFを切り替える手法トランクベース開発で未完成の機能をリリースに含めるが、実行されないように隠すためにFeatureFlagを使用する https://martinfowler.com/articles/feature-toggles.html 01

Slide 11

Slide 11 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlagを使ったトランクベース開発 01 main(trunk) Release 1.0 Release 1.1 branch-A branch-B 未完成の機能実装 FeatureFlag OFF 🚩FeatureFlag ON 機能の完成

Slide 12

Slide 12 text

Flutterリプレイス後のFeatureFlag運用  前提知識1/2：アプリチームの開発状況 ● FeatureFlagを使ったトランクベース開発をリプレイスプロジェクト開始時から3年以上運用 ● 運用フェーズ後の新機能追加時はFeatureFlagを使用して機能を閉じながらアプリを毎週リリース ● 常に20個弱のFeatureFlagをプロジェクトコードに埋め込みながら2~3機能を同時並行開発 ● 新卒を積極的に配属して既存コードの理解が浅いメンバーの急増 01

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Flutterリプレイス後のFeatureFlag運用  前提知識2/2：アプリのレイヤー構成 Domain 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service UI State Domain Data

Slide 15

Slide 15 text

Flutterリプレイス後のFeatureFlag運用  前提知識2/2：アプリのレイヤー構成 State 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service UI State Domain Data

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Flutterリプレイス後のFeatureFlag運用  前提知識2/2：アプリのレイヤー構成 https://developers.cyberagent.co.jp/blog/archives/36149 01

Slide 18

Slide 18 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01

Slide 19

Slide 19 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01

Slide 20

Slide 20 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlagの使用用途 ● 開発中の機能を細かいPRに分けてトランクにマージしてPRのリードタイムを短縮したい ● コンフリクトを発生しにくくしたい ● リリース時に不具合があったときに切り戻したい ➢ 新機能開発、大規模なリファクタリング ● 機能の効果検証をしたい ➢ 新機能開発の ABテスト 01

Slide 21

Slide 21 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01

Slide 22

Slide 22 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装内製のFeatureFlagクライアントを使用 2つのタイプの実装 ● workInProgress ○ SharedPreferencesでいつでも手元でFeatureFlagの切り替えが可能 ○ 開発中に使用 ● ops ○ Firebase RemoteConfigでリリース無しでFeatureFlagの切り替えが可能 ○ 機能リリース時に使用 01

Slide 23

Slide 23 text

Flutterリプレイス後のFeatureFlag運用  Feature Toggles (aka Feature Flags) https://martinfowler.com/articles/feature-toggles.html 01

Slide 24

Slide 24 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlagのカテゴリ分類 ● どれくらい切り替わる頻度が多いか？ ● どれくらい生存期間が長いか？ Feature Toggles (aka Feature Flags) 01 https://martinfowler.com/articles/feature-toggles.html

Slide 25

Slide 25 text

Flutterリプレイス後のFeatureFlag運用  WINTICKETでの利用カテゴリ 01

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装基本的なフラグ制御方法 ● FeatureFlagClient.get() 01

Slide 28

Slide 28 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装 UIでのフラグ制御方法① ● useFlag UI(build関数)内で実行するロジックを制御ボタン押下処理・hooks内の処理など 01

Slide 29

Slide 29 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装 useFlagの実装↓ 01

Slide 30

Slide 30 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装 UIでのフラグ制御方法② ● FlagBuilder Widgetの出し分けを制御 01

Slide 31

Slide 31 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装 FlagBuilderの実装↓ 01

Slide 32

Slide 32 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装画面遷移時のフラグ制御方法 ● FlagGuard AutoRouteのRouteGuards機能を使用した自前実装のGuardを用意画面遷移時に画面遷移を許可するかのロジックを実装できる DeepLinkでの遷移も防げる 01

Slide 33

Slide 33 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag実装 FlagGuardの実装↓ 01

Slide 34

Slide 34 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag運用 1. FeatureFlagの使用用途 2. FeatureFlag実装 3. FeatureFlagの導入原則 01

Slide 35

Slide 35 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag導入原則できるだけデータフローの根源で絶つ 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service UI State Domain Data

Slide 36

Slide 36 text

Domain Flutterリプレイス後のFeatureFlag運用  FeatureFlag導入原則できるだけデータフローの根源で絶つ ● サーバーAPIの変更があったときは UseCaseでFeatureFlag制御 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service 🚩   GET  v1→v2 UI State Data

Slide 37

Slide 37 text

Flutterリプレイス後のFeatureFlag運用  FeatureFlag導入原則できるだけデータフローの根源で絶つ ● UIの変更があったときはUIで FeatureFlag制御 01 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service 🚩   Button  Red→Blue  UI State Domain Data

Slide 38

Slide 38 text

02 従来のFeatureFlagを使用した開発

Slide 39

Slide 39 text

従来のFeatureFlagを使用した開発   従来の開発フロー 02 設計実装動作確認 QC リリース ﬂag削除

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読  ②：Domain呼び出し  購読のやりかたにミス ④が実行されない 󰢃 UI 

Slide 55

Slide 55 text

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読  ②：Domain呼び出し  購読のやりかたにミス ④が実行されない 󰢃 不具合発生 🚨 UI 

Slide 56

Slide 56 text

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読  ②：Domain呼び出し  既存のデータフローも無いので切り戻しできない UI 

Slide 57

Slide 57 text

発生した不具合の分析と整理   実際の不具合発生ケース 03 Domain  UI  ①：イベント購読  ④：③がきたらDomain呼び出し  Domain  ③：イベント購読  ②：Domain呼び出し  理想は既存には手を触れずに改修どちらのデータフローも実行できるようにフラグ分岐 🚩 UI 

Slide 58

Slide 58 text

Slide 59

Slide 59 text

発生した不具合の分析と整理   実際の不具合発生ケース UI既存改修での不具合 ● hooks、Providerのlistenのコールバック内での分岐漏れ ● FlagBuilderのbuilder内での分岐漏れ 03

Slide 60

Slide 60 text

発生した不具合の分析と整理   実際の不具合発生ケース Route追加での不具合 ● FlagGuardを追加していたがmetaの設定忘れ 03

Slide 61

Slide 61 text

発生した不具合の分析と整理   実際の不具合発生ケース Domain新規追加での不具合 ● 新規Domain追加時にFeatureFlagの制御の入れ忘れ ● 新規Domainを既存画面からアクセスされたときに実行しないようにする対応漏れ 03

Slide 62

Slide 62 text

発生した不具合の分析と整理   実際の不具合発生ケースまとめ ● 既存改修が複数レイヤーで起こると不具合が発生しやすい ● 既存は変更をしないように改修したい 03 Domain UI 不具合発生頻度新規追加新規追加低既存改修新規追加低新規追加既存改修中既存改修既存改修高

Slide 63

Slide 63 text

発生した不具合の分析と整理   課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようする 03

Slide 64

Slide 64 text

発生した不具合の分析と整理   課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようする既存改修するときは、既存の実装には触れずそのままの実装をFeatureFlag で切り戻せるようにするたとえ実質挙動が一緒にできても、既存実装は手を加えない 03

Slide 65

Slide 65 text

発生した不具合の分析と整理   課題に対するアプローチ 1. 既存は触れずに残しながら改修できるようにする 2. 制御忘れに機械的に気付けるようにしたい実装者もレビュー者も人間なので忘れてしまうときはあるできるだけ人間が直接関与しないようにする 03

Slide 66

Slide 66 text

発生した不具合の分析と整理   コードベース以外の考慮 ● 若手が多いチーム構成 ● 組織拡大時期で人の流動性が高い ● 他の横軸並行タスクが多く、ヒューマンエラーが起こりやすい中堅メンバーの能力に頼らず、いつでも誰でも安全に FeatureFlag制御できるような実装制限をかけたい 03

Slide 67

Slide 67 text

発生した不具合の分析と整理   解決したいことの整理 ● アプローチ ○ 既存は触れずに残しながら改修できるようにする ○ 制御忘れに機械的に気付けるようする ➢ 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限をかけたい 03

Slide 68

Slide 68 text

04 可用性向上のための運用戦略とその方法

Slide 69

Slide 69 text

可用性向上のための運用戦略とその方法   運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04

Slide 70

Slide 70 text

可用性向上のための運用戦略とその方法   運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

可用性向上のための運用戦略とその方法   実際の不具合から考える運用戦略 ● 既存は触れずに残しながら改修できるようにする ● 若手から中堅まで誰でも同じレベルで可用性を向上させられる実装制限をかけたい ● 制御忘れに機械的に気付けるようするレビュー時に機械的に気付けるように 04

Slide 73

Slide 73 text

可用性向上のための運用戦略とその方法   実際の不具合から考える運用戦略 1. 既存の実装には全く手をつけない実装制限をかける 2. 機械的に気付けるようにする 04

Slide 74

Slide 74 text

Slide 75

Slide 75 text

可用性向上のための運用戦略とその方法   実際の不具合から考える運用戦略実装制限のかけかた ● 制御レイヤーの制限 ● 分岐制御の制限 04

Slide 76

Slide 76 text

可用性向上のための運用戦略とその方法   運用戦略 - 制御レイヤーの制限できるだけデータフローの根本のDomainだけで分岐が完結できると、UIと Domainでのデータフローでミスが起こりにくくなる 04 UI  State  Domain  Data  Source  ON：文字列 OFF：空文字  UIは文字列があるかどうかで表示を制御 FeatureFlagは意識しない  データフロー 🛠FeatureFlag分岐

Slide 77

Slide 77 text

可用性向上のための運用戦略とその方法   運用戦略 - 制御レイヤーの制限理想は制御レイヤーをDomainだけに絞りたい Domainだけで制御できるように実装者が設計することで、デグレしにくい制御ができるようにする 04 UI  State  Domain  Data  Source 

Slide 78

Slide 78 text

可用性向上のための運用戦略とその方法   運用戦略 - 制御レイヤーの制限 UIのみの改修の場合はUIでしかFeatureFlag分岐はできない ● 例 ○ ボタンの文言の切り替えで ABテストしたい ○ ボタン押下したときの遷移先を変更したい 04 UI  State  Domain  Data  Source 

Slide 79

Slide 79 text

可用性向上のための運用戦略とその方法   運用戦略 - 制御レイヤーの制限従来通り、制御レイヤーは基本 UI・Domainレイヤーのみにするこれ以外の特殊な例外は一部Stateも許容する 04 Connected Screen Stateless Screen Widget Selector State UseCase Persistence Service 🚩 🚩 UI State Domain Data

Slide 80

Slide 80 text

可用性向上のための運用戦略とその方法   運用戦略 - 分岐制御の制限 ● FeatureFlagをbool値で扱うと自由度が高すぎて簡単に複雑なロジック制御が可能になる ● 既存のif文に組み合わせたり、三項演算子に混ぜたり Domainでは不具合が発生した例はなかったのでUIのみ制限をかける 04

Slide 81

Slide 81 text

可用性向上のための運用戦略とその方法   運用戦略 - 分岐制御の制限 UIではシンプルなboolでFeatureFlagを取り出せないようにして、ONとOFFの処理を明示的に分けるインターフェースでしかフラグ分岐できないようにする 04 Before After

Slide 82

Slide 82 text

可用性向上のための運用戦略とその方法   運用戦略 - 分岐制御の制限分岐制御の制限によって、既存の実装はコピペで残して触れずに避ける 04 改修後改修前

Slide 83

Slide 83 text

可用性向上のための運用戦略とその方法   運用戦略 - 分岐制御の制限 04

Slide 84

Slide 84 text

可用性向上のための運用戦略とその方法   運用戦略 - 分岐制御の制限 04 変更はここのみこの辺は冗長だが、可用性を重視

Slide 85

Slide 85 text

可用性向上のための運用戦略とその方法   運用戦略 1. 既存の実装には全く手をつけない実装制限をかける 2. 制御忘れに機械的に気付けるようする 04

Slide 86

Slide 86 text

可用性向上のための運用戦略とその方法   運用戦略 - できるだけ機械に任せたい 1. 新規ページ追加時FlagGuardの設定忘れ FlagGuardがないときにPull Request上でDangerでwarning 04

Slide 87

Slide 87 text

可用性向上のための運用戦略とその方法   運用戦略 - できるだけ機械に任せたい Danger CIプロセス中に実行できて、一般的なコードレビュー作業を自動化するツール https://danger.systems/ruby/ 04

Slide 88

Slide 88 text

可用性向上のための運用戦略とその方法   運用戦略 - できるだけ機械に任せたい 2. UseCase追加時にFeatureFlag制御がない新規追加時Dangerで警告 04

Slide 89

Slide 89 text

可用性向上のための運用戦略とその方法   運用戦略 1. 実際の不具合から考える運用戦略 2. 開発フローから見る運用戦略 04

Slide 90

Slide 90 text

可用性向上のための運用戦略とその方法   開発フローで見る戦略 ● 実装方針レビューでFeatureFlagについてレビューできるように 04 設計  実装動作確認 QC リリース ﬂag削除追加

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

可用性向上のための運用戦略とその方法   検討して採用しなかったこと 04 ● 課題に対する大きな変更 ○ Gitflowな開発 ○ プロジェクトコード全体のリアーキテクチャ ○ 理想形の追求 ● 課題が起きていない箇所への変更 ● FeatureFlagの利用方針 ○ UIに近いところで分岐

Slide 95

Slide 95 text

05 対応した結果と今後の展望

Slide 96

Slide 96 text

対応した結果と今後の展望   可用性と利便性のトレードオフ 05 可用性高利便性高利便性低可用性低理想現実

Slide 97

Slide 97 text

対応した結果と今後の展望   メリット 1. FeatureFlagによる制御漏れのミスはゼロに 2. いい意味で自由度がなくなり、実装時に誰でもFeatureFlag設計を考えられるように 05

Slide 98

Slide 98 text

対応した結果  デメリット 04 1. シンプルなboolの制御がないと厳しい場面がある 2. 可用性を考えるよりも冗長さが勝るときがある 3. Lintや設計のような強い制限ではないので新メンバーが迷う

Slide 99

Slide 99 text

対応した結果  デメリット 1. シンプルなboolの制御がないと厳しい場面がある UIから参照しているメソッドの中の一部を分岐したいとき UIからboolを渡してメソッド内で分岐したい 04

Slide 100

Slide 100 text

対応した結果  デメリット 04 2. 可用性を考えるよりも冗長さが勝るときがある Widgetのbuild()内で参照している他のメソッドの中身を別なロジックにに分岐したい ref.listen()してる中の処理を分岐したい

Slide 101

Slide 101 text

対応した結果  デメリット 04 3. Lintや設計のような強い制限ではないので新メンバーが迷う Pull Requestで初めて「そういう決まりあったんだ」になることが多々あるドキュメントは古くなりやすく、読まれづらい

Slide 102

Slide 102 text

対応した結果と今後の展望   今後の展望可用性以外の利便性の向上 ● 自動でRemoteConfigに追加 ● RemoteConfigでFeatureFlagが変更されたら通知 ● 可用性を考慮した迷いがないFeatureFlag実装 ● ABテスト設定の自動化 ● DangerからCustomLintへの置き換え 05

Slide 103

Slide 103 text

ご清聴ありがとうございます  

Slide 104

Slide 104 text

参考  参考 ● 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/