Feature Flag Deep Dive 株式会社サイバーエージェント AI事業本部 岩 見 彰太 GitHub:@BIwashi X: @B_Sardine

自己 紹介 岩 見 彰太 / Iwamin 株式会社サイバーエージェント ೥౓৽ଔೖࣾ "*ࣄۀຊ෦ڠۀϦςʔϧϝσΟΞ%JW খചاۀͷΞϓϦ։ൃ @BIwashi @B_Sardine

1 .ブランチ戦略 2 .トランクベース開発とは 3 .feature fl ag とは 4 .今のPJTにおける feature Flag 5 .feature fl ag の種類 6 .feature fl ag で実現できること 7 .OpenFeature とは 8 .OpenFeature があると何が嬉しいか 9 .feature fl ag の SaaS について 10 .Appendix: 作りたい ・ 整えたい周辺ツールの話

目 的 • 「feature fl ag が〜」「トランクベース開発が〜」みたいなワードを全員が なんとなく理解する • backend のリリースフローについて理解する •「prod にv 1 . 0 . 1 をリリースします！ fl ag はまだ有効化してません！」の 言 ってる意味がわ かるようにする •ABテストなどをしたい場合に何を考慮すればいいかがなんとなくわかる

ブランチ戦略

ブランチ戦略とは • Git 上で別々の作業を並 行 して 行 う仕組み = ブランチ •ブランチをどのように運 用 していくかという戦略 • どのような戦略を取るかどうかによって、デプロイ速度や開発 生 産性、シス テムの品質に 大 きく影響してくる • ブランチ戦略には主に 大 きく分けて2種類存在する（他にもGitLab Flow と か存在する） Git Flow GitHub Flow

• 5種類のブランチが存在（main/develop/feature/release/hot fi x） • 特徴 •main と develop の乖離が発 生 しやすいため、開発頻度の 高 いチームでは最新ブランチの状 態を維持するのが難しため、コンフリクトが発 生 しやすい •release が 大 きくなる、いわゆるビックバンリリースになってしまうため、どこか 一 つでも 不具合があるとロールバックする必要がありなかなかリリースできないことが起こってしま う Git Flow トランクベース開発について - 赤 帽エンジニアブログ

Git Flow mainから develop を切る トランクベース開発について - 赤 帽エンジニアブログ

Git Flow develop から feature を切る トランクベース開発について - 赤 帽エンジニアブログ

Git Flow feature branch で開発する トランクベース開発について - 赤 帽エンジニアブログ

Git Flow develop に merge する トランクベース開発について - 赤 帽エンジニアブログ

Git Flow 機能が全てできたら release を 切って release 準備をする トランクベース開発について - 赤 帽エンジニアブログ

Git Flow 準備ができたら main に merge develop にも release の修正を反映 トランクベース開発について - 赤 帽エンジニアブログ

Git Flow 修正が発 生 する場合は main から hot fi x を切って対応する トランクベース開発について - 赤 帽エンジニアブログ

• 2種類のブランチが存在（main/feature） • Git Flow をシンプルにしたもの • 特徴 •使 用 される branch が少ないので認知負荷が低い •ブランチが環境と紐づかないため、prod に対する修正をしたい場合は最後の release tag か ら hot fi x 用 のブランチを切って対応しないといけない GitHub Flow トランクベース開発について - 赤 帽エンジニアブログ

GitHub Flow main から feature を切る トランクベース開発について - 赤 帽エンジニアブログ

GitHub Flow main に merge して stg などで テストする トランクベース開発について - 赤 帽エンジニアブログ

GitHub Flow test が問題なければ prod にリリ スする トランクベース開発について - 赤 帽エンジニアブログ

トランクベース開発とは

トランクベース開発とは • 直接 main に対してどんどん merge していくスタイル • branch は1~2 日 以内に merge する短命なものでなくてはいけない • 特徴 •マージに伴うコンフリクトを最 小 限にできる •変更が加えられた main branch は常に prod に 反映される •開発単位を 小 さく保ち、頻繁に main に pushし、 それに伴い CI/CD を実 行 して 自 動テストや脆弱性 診断の FBK を素早く得ることで開発スピードと デプロイまでの時間短縮を実現している トランクベース開発の trunk は Subversion というバージョン管理システム における main のことを trunk と呼んでいたらしい トランクベース開発について - 赤 帽エンジニアブログ

今の PJT では…？ • トランクベース開発（もどき） • バックエンド側で「release」と 言 っているものには2つ意味がある release tag を打った場合 • 現時点での main に tag を打ってその状態を記録する • この時点でパッチバージョンが上がる（v 1 . 0 . 1 7 -> v 1 . 0 . 1 8 ） • この時点では tag を打っただけでインフラの更新はない 各環境の version を変更した場合 • dev は main にマージされるたびに最新のバージョンでデプロイされる（by PipeCD） • stg, prod は毎度明 示 的に version を指定する • このタイミングでデプロイが 行 われる • ex.) v 1 . 0 . 17 -> v 1 . 0 . 1 8 • パッチバージョンの差分にはいくつかの修正が含まれている • dev: トランクベース開発 • stg, prod: GitHub Flow のリリースフロー

今の PJT では…？（追加訂正） • トランクベース開発はあくまでもいつで もリリース or デプロイできる状態にす るためのプラクティス • GitHub Flow をより 高 速にかつ複雑度を 下げるため 手 法であり、GitHub Flow と ランクベース開発が別という話ではない （そもそも種類が違う）

feature fl ag とは

feature fl ag とは • コードを変更することなくシステムの振る舞いを変更可能にする仕組み • 利点と使い所や課題 •トランクベース開発においては修正を fl ag 付きで実装しておくことで、その機能の反映可否 をコードを変更することなく 行 えるようにできる •「 fl ag 付きで実装する = fl ag を含む if 分岐で実装を囲んでおくことによっていつでもその実装を有効化無効化できるよ うに実装をしておく」 •役割を終えたら feature fl ag を削除する、といいうのを徹底してやらないとコードが複雑化 してしまう •feature fl ag の実装は属 人 化しがちなので、早めに実装した 人 が削除しないと簡単に負債化してしまう The Go gopher was designed by Renée French. GO Feature Flag

HOGE_FLAG := true if HOGE_FLAG == true { // flag ON ͷ࣌ʹ࣮ߦ͍ͨ͠ॲཧ // ex.) ൓ө͍ͨ͠मਖ਼ // ex.) AB ςετͷ A Λ༗ޮԽ͢Δ // ... } else { // flag OFF or flag Λઃఆ͍ͯ͠ͳ͍࣌ʹ // ࣮ߦ͍ͨ͠ॲཧ // ex.) मਖ਼લͷطଘͷ࣮૷ // ex.) AB ςετͷ B Λ༗ޮԽ͢Δ // ... } 実装イメージ • HOGE_FLAG とういう fl ag が ON だっ た場合と OFF だった場合の処理を if 文 で書く • AB テストや特定の実装を有効化する場 合などに使える The Go gopher was designed by Renée French. GO Feature Flag

今のPJTにおける feature Flag

今の PJT と feature fl ag • PR が approve されたら main に merge される •main に変更が含まれる •dev には 自 動リリースされる •この時点で release tag を打つとどうなるか •その release に main の変更が含まれる •stg にその version をデプロイする •stg には release tag を打ったタイミングのいくつかの修正が含まれる •stg ではいくつかの修正が含まれている •A：テスト済 •B：テスト未 •prod に先に A の修正をリリースしたい •先ほど打った release には A, B が含まれている •prod の version を上げる（デプロイする）とA, B の修正が両 方 prod に上がってしまう •これが嫌な場合は B のテストが終わるまで A のリリースができない😇（その release tag に含まれているすべての修正がリリース可能な状態で あることが確認できないとリリースできない） The Go gopher was designed by Renée French.

今の PJT と feature fl ag

今の PJT と feature fl ag

今の PJT と feature fl ag ここでは prod は A のみ有効

今の PJT と feature fl ag これが本来のトランクベース開発のあるべき姿 今はリリース前までのトランクベース開発ではなかった時の名残が混ざっている prod にすぐ出したくない修正は fl ag で回避している前提なので release tag はあまり意味がない

今の PJT と feature fl ag（追加訂正） • トランクベース開発はあくまでブラン チの運 用方 法の話で、実際に deploy するかどうかはまた別の問題 • トランクベース開発は「prod に常 に”リリース可能な状態”にする」こ とであって、実際にリリースするかど うかはデプロイ戦略の 文 脈の話になる

今の PJT と feature fl ag（追加訂正） • トランクベース開発とデプロイ戦略は別 文 脈 • Continuous Deployment •全ての修正が 自 動的に production にデプロイされる • Continuous Delivery •デプロイするか否かを選択することができる •トランクベース開発はあくまでいつでもデプロイで きるようにしておくまでで、実際にどうデプロイす るかは別で考える必要がある • 必ずしも全て Continuous Deployment すべきと いうわけではない • feature fl ag の実装ミスや QA フローなどによっては併 用 し た 方 がいい場合もある The Journey of Software Delivery - Speaker Deck

Deep Dive

feature fl agの種類

• feature fl ag にはいくつかカテゴリがあり、それぞれの 用 途によってライフ サイクルやON/OFF の頻度などが異なる • 適切に理解して使 用 する必要がある • （feature fl ag と feature toggle という2つの呼び名が存在するが 同じもの） feature fl ag の種類 The Go gopher was designed by Renée French. Feature Toggles (aka Feature Flags)

• トランクベース開発を可能にするために使 用 • 進 行 中の機能を main に merge して、いつでも本番環境に展開できるように する • 1~2週間以上存在してはいけないことが推奨 されている • 基本的に静的 （request単位などでON/OFFが切り替わる ようなものではない） Release Toggles

• A/Bテストやカナリアリリースを実現するために使 用 • 仮説検証 用 の実装や 一 部のユーザーに限定して機能を公開する場合などに使 用 される • データ駆動型の最適化に使 用 される • A/Bテストなどの場合は有意なデータを収集する ために 十 分な期間が必要だが、システムに変更 を加えてしまうとその影響が載ってしまう可能性 があるため、時間や週単位が推奨されている Experiment Toggles

• システム動作の運 用面 の制御に使 用 • パフォーマンスへの影響が不明確な新機能をロールアウトする際に導 入 し、 必要に応じて無効化や低下をできるようにする • 障害発 生 時のリカバリー 用 として使 用 する • テクニックとして、システム全体の負荷が 高 まっ てしまった際に重要ではない機能を OFF にして 対応する 「Circuit Breaker」としての機能も あるらしい Ops Toggles

• 特定のユーサーのみ機能を加えたり、特別な機能を解放する場合などに使 用 • 課 金 ユーザーや PoC の対象者に限定的に機能を解放するなど • Experiment Toggles が仮説検証のA/Bテストなどの 用 途であったのに対し、 Permissioning Toggles はすでに完成している 機能の限定公開の 用 途として使 用 される Permissioning Toggles

feature fl ag で実現できる こと

• トランクベース開発での使 用 • A/Bテスト • 真の意味でのカナリアリリース •実は PipeCD のカナリアリリースは厳密な割合でのリリースはできない •特定のユーザー限定の機能の有効化 •ダークカナリアリリース •テスト実 行 者や開発者など特定のユーザーのみ機能を有効化する •これをちゃんと使いこなせたら stg をなくせるかもしれない feature fl ag で実現できること

OpenFeature とは

• CNCFのインキュベーションプロジェクトにも採択されているOSS • feature fl ag管理のオープン標準規格を実現するための抽象化層として作 用 す るSDK • Bucketeerのような feature fl ag 自 体を管理するOSSではなく、あくまで feature fl ag を管理するサービスとの間に位置する抽象化層 • Provider を介して、対応している feature fl ag service と繋ぐことができる • Provider の interface を実装すると任意の custom provider を作れる • Dynatrace が実は主導している OpenFeature とは

OpenFeature とは Introduction | OpenFeature

OpenFeature があると 何が嬉しいのか

• ベンダーロックインを避けられる •好きな feature fl ag service に気軽に乗り換えられる •複数のツールを使うことも許容できる（その場合でも使い 方 を統 一 できる） OpenFeature のなにが嬉しい？ つらい例 綺麗になる例 フィーチャーフラグを抽象化するOpenFeatureとは？ | Think IT（シンクイット）

feature fl ag の SaaS について

• めっちゃある（検討中…) • MAU 課 金 なので、feature fl ag の 用 途に応じて適切に選択する必要がある • 「 fl ag を管理している SaaS に fl ag の値を確認しに 行 く数」に応じて課 金 が 発 生 するので、動的な fl ag（toggle）に使うべき • トランクベース開発の fl ag（Release Toggles）については無理に使わなくて もいい •実際に今は環境変数で管理している feature fl ag の SaaS

Appendix: 作りたい ・ 整え たい周辺ツールの話

• fl ag 作成後 一 定期間経ったら通知をしてくれる •削除するように促して、不要な fl ag 実装を削除するようにする •ASTとかを使って feature fl ag の実装を 自 動計装 ・ 削除する •計装を 自 動化できるようにする •削除はすでにやっている例がある •GoのASTを解析してFeature Toggleを掃除する - freee Developers Hub •interface などの具体的なSDK周りの実装を protoc plugin で 自 動 生 成する •feature fl agの依存関係をvalidationする実装を 自 動 生 成する •OpenFeature の Provider を環境によって分ける •stg：SaaS •prod：環境変数を読む custom provider 周辺ツール

fi n.

• DevOps 技術: トランクベース開発 | Cloud アーキテクチャ センター | Google Cloud • 軽量feature fl ag導 入 の 手 引き #devops - Qiita • 今話題のトランクベース開発について調べた • OpenFeatureとは何なのか • フィーチャーフラグ導 入 のハードルを下げたい • Goで書いたAPIにOpenFeatureを 入 れたい • 開発速度UP⤴ ！UX UP⤴ ！利益⤴ ！フィーチャーフラグはDevCycleで50ミリ秒以下の世界に 🚀 • Edge Flags | DevCycle • Feature Toggleについて整理してみました - SRE兼スクラムマスターのブログ • GoのASTを解析してFeature Toggleを掃除する - freee Developers Hub • フィーチャーフラグにはタイプ（リリース ・ 実験 ・ 運 用・ 許可）がある！ - kakakakakku blog • フィーチャーフラグを管理するためのOpenFeature | フューチャー技術ブログ • Simple Feature Flagging for All | GO Feature Flag • Chromium Docs - Chromium Flag Ownership • トランクベース開発について - 赤 帽エンジニアブログ • トランクベース開発におけるフィーチャーフラグの活 用 法｜Harness正規販売代理店（株）Digital Stacks • What are Feature Flags and How Do We Use Them? | Harness • こんなフィーチャーフラグは気をつけろ！ - Secret Ninja Blog • トランクベース開発をしてみたときの理想と現実 • フィーチャーフラグを抽象化するOpenFeatureとは？ | Think IT（シンクイット） • OpenFeatureがCNCFの 支 援プロジェクトに 　 フィーチャーフラグのための標準APIを提供：さらなる標準化を 目 指す 方 針 - ＠IT • Feature Toggle Types | Unleash • Feature Toggles (aka Feature Flags) • Feature Flags + A/Bテスト システム 機能 比 較 2022年6 月 版 • Trunk-Based Development And Branch By Abstraction 参考資料