ABテストの運用を始めたり、フィーチャーブランチ(機能ブランチ)の運用で課題を感じた際にフィーチャートグルで対応できるかもしれません。
フィーチャートグル(機能トグル、フィーチャーフラグ)のSaaSで有名なLaunchDarklyを試してみました。
フィーチャートグルとは
gitでのフィーチャーブランチでの開発の進め方とは別に、フィーチャーフラグによって機能管理する手法です。
ソースコードに乖離が発生する前にmasterに積極的に機能offの状態でマージしていこうぜ、と。
中〜大規模な機能ブランチが並列で走り、マージ/リベース時に苦しんだ事はありますでしょうか。
誰かが1ヶ月前に行ったリファクタがマージされ自分のリファクタ対象ファイルがそもそも無くなっていた事はありますでしょうか。
そうではなくて機能offの状態で細かくマージしていきましょうという志向。
Wikipediaのフィーチャートグルの説明が分かりやすいです。
継続的リリースと継続的デプロイは、コーディングについてのフィードバックを開発者たちに頻繁に提供してくれる。これを実現するには、複数の開発者たちのコードを可能な限り早期に統合することが必要になる。
機能ブランチはこの過程に抜け道を作ってしまう。機能トグルを利用すれば、開発者たちはメインのトラックに頻繁にソースを統合しつつも、開発中の機能へ入っていける実行経路のトグルを「OFF」にしておけば、その機能は「死んだ」状態になる。新しい実行経路を有効にするための労力は、単にトグルを「ON」に設定するだけなので、十分に小さい。
カナリアリリース。
機能フラグの別の利点は、カナリアリリースである。
そしてこれは銀の弾丸ではありません。
マーティン・ファウラーは機能トグルは最後の手段であるべきとして、機能トグルを利用する前に次のような手段を検討すべきと述べている。
機能を小さく分割して段階的にリリースしていく方法
新機能へのエントリーポイントとなるUIを最後に作る方法
Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた
フィーチャートグルの具体的な使用法について記事翻訳。非常にありがたい。
LaunchDarklyのサンプルiOSアプリを動かしてみる
30日間の無料試用があるのでサインアップ。
ログインするとダッシュボード画面。
早速テスト用のFeatureFlagを登録
CRAATE FEATURE FLAG + ボタンをクリックし
各種情報を入力して SAVE FLAG。
できました。
Account settings の開発用コードをメモっておく
サンプルアプリダウンロードし実行する
LaunchDarkly SDK for iOS (Swift)
pod install。
先ほどメモした開発者コード部分を書き換えます。
// Enter your mobile key here: Account Settings -> Your Projects -> Production/Test -> Mobile key.
private let mobileKeyTest = ""
(中略)
private func setUpLDClient() {
let userBuilder = LDUserBuilder()
userBuilder.key = ""
let config = LDConfig(mobileKey: mobileKeyTest)
config.streaming = true
LDClient.sharedInstance().start(config, with: userBuilder)
}
// Enter your feature flag name here.
fileprivate let featureFlagKey = "new-search-bar"
出ました！
フラグ値を変えてみる
アプリを起動したまま、WebのDashboardから値を変更してみます。
即時に変更されました。
これはSDKでStream受信しているからです。
雑感
割りと前から存在する技術/概念だけれど、来年以降もう少し流行る予感。
自分はこれまで使った事がなかったけれど既に使っている企業では今更感があるかもしれぬ。
ルール無しに使うとカオスになる予感。
知見が溜まったら共有します。
Apple審査通過しリリース後に大きな機能をonにするような運用するとアプリ毎停止されるはずなので注意しましょう。
toBアプリやtoBサービスで[○○社向けカスタマイズフラグ]などクライアントの名前が付いたフラグが登場してくると、開発複雑度が激増し崩壊の匂いがしてくる。
が、これはそういったカスタマイズフラグではないと声を大にして言いたい。