スタンドアロン（またはネイティブ）アプリと LaunchDarkly によるカナリアリリースの課題
概要：
スタンドアロンアプリ開発（Webアプリではなく）にて LaunchDarkly によるカナリアリリースを行っていますが、ある問題が発生しています。 いくつか策はありますが、一般論や似たような事例があるはずで、それを知りたいですが、手詰まりな状態です。
LaunchDarkly をどのように使っているか
スタンドアロンアプリにおいて、LaunchDarkly の短期の機能フラグを以下のメリットのために使います。
メリット：
流れ：
- フラグで一部ユーザーのみに開放する
- 改善を行う
- フラグで全ユーザーに開放する
- 安定稼働を見届ける
- フラグを参照しないバージョンをリリースする
- フラグを削除する
問題
Web アプリでは問題ないですが、スタンドアロンアプリの場合、以下の問題が生じます。
例：
- Ver 1.x.x フラグで一部ユーザーのみ開放する
- 改善を行う
- Ver 2.x.x をリリースしたとする
- リリースしたいタイミングで、フラグで全ユーザーに開放する
最後のステップ「フラグで全ユーザーに開放する」にて、Ver 1.x.x を使うユーザーにも機能が開放されることになります。Ver 1.x.x の時点で既に品質がよければ問題ありませんが、そうでなければ、品質が悪い機能が提供されることになります。
問題：
- 「LauchDarklyの短期の機能フラグで一部ユーザーに公開しつつ、改善を続け、任意のタイミングで全開放」という開発が行いにくい。
この問題は、以下の問題に類似しており、”古いバージョンを使うことによる問題点” の一種と思われます
- とあるバージョンにてバグの修正版をリリースしたが、まだアップデートしていない人にはバグ混入バージョンを提供していることになる
回避策
A 強制アップデート
強制アップデートにすれば、スタンドアロンでもほぼ Web アプリと同様に最新版のみを提供できることになり、上記の問題は発生しません。 ただし、強制アップデートを使えない事情があるため、この案は採用できないと仮定します。
B ベータテストと、カナリアリリースのための2つのフラグを使う
ベータテストのためのフラグ beta-flag と、カナリアリリースのためのフラグ feature-flag を用意します。
流れ：
- 一部ユーザーのみに提供するため、
beta-flagがONであれば使える状態でリリースする - 全ユーザーに公開しても良い段階にする
- 全ユーザーに提供するため、
feature-flagがONであれば使える状態でリリースする- このとき、
beta-flagは 削除するなどで OFF にする
- このとき、
冒頭のメリットについて
- ベータテスト：リリース前に、一部ユーザーなどの一部のみに開放する
- → ベータテストのためのフラグを設ける
- カナリアリリース：異なるバージョンのアプリをデプロイしなくても、機能を提供できる
- → △ カナリアリリースのためのフラグを設けたバージョンをリリースする必要がある
C バージョンを参照する
フラグは、boolean だけではなく、文字列や JSON も設定可能なことから、3 種類の値を持つフラグを設けます。
- "ON"（常に有効）
- バージョンの値：例："2.0.0"（2.0.0以上のみ有効であることを表す）
- "OFF"（常に無効）
スタンドアロンアプリ側で、フラグがバージョンの値であるときは、自身のバージョンの値と比較して ON、OFF かどうかを判断します。
流れ：
- 一部ユーザーのみに提供するため、1.x.x をリリースする。フラグのバージョンの値を "1.x.x" にする
- 全ユーザーに公開しても良い段階にする
- 2.x.x をリリースする
- 全ユーザーに提供するため、フラグのバージョン値を "2.x.x" にする。
- このとき、バージョン 1.x.x を使っているユーザーは使えない状態になる
- フラグを参照しないバージョンをリリースする
冒頭のメリットすべて得られるため、これが理想に思います。
参考サイト
- 7 Feature flag best practices - LaunchDarkly | LaunchDarkly
- Release Management Best Practices with Feature Flags | LaunchDarkly | LaunchDarkly
- Beta Testing using Feature Flags | LaunchDarkly
- Martin Fowler / Feature Toggles (aka Feature Flags)
言葉のメモ
楽譜で音ゲー ver.2 のイメージ動画を作成した
次に作ってみたい音ゲーのイメージ動画を作成した。
BGM提供 : Hagall https://hagall.info/
- 譜面は左右の2に分かれ、左・右・左・右と移っていく
- ノーツは動かない
なぜこのかたちになったか
前回の音ゲーは目が疲れる
前回作った音ゲー↓ で、一つ困る点があったのでそこを変更した。
困る点
- ノーツが横に流れて目が疲れてしまう
- フレームレートや作りが良くないかもしれない
- そもそも楽譜は動くものではなく静止している
- 音の長さは音符で表しているので、動くことでタイミングを示す必要性はない
- → ノーツは動かないようにした
テキストストリーミングを試してみたい
また、ピアノを演奏していて、”今の小節のところに視線を合わせるのが疲れる”と思い、そういえば、Spritz サービスのテキストストリーミングという方法を思い出し、楽譜にも適用できるのではないかと思った。
文字を次々に表示させ、まるで話すようなテンポで文章を読み進めていけるようにする技術が「Spritz」です。
そこで、楽譜を1小節ずつ表示してみることにした。その動画はこちら↓
しかし、1小節だと次の小節の予測ができず、演奏が辛いことが分かった。そこで、2小節で表示してみることにした。その動画はこちら↓
2小節だと良い感じに思えた。ただどの早さで演奏すればいいのか分からず、前の小節に戻ることもできないので、演奏の練習には向かないと思った。そこで音ゲーにしようと思った。
ただ、この2小節の方法だと、”次は右なのか左なのか？”という迷いが生じる。そこで、方向は固定にしてスライドさせる、ところてん方式を試してみた↓
うーん、楽譜が動くとやはり気になってしまう。アニメーションの改善で良くなるかもしれない。
ということで、今のところ冒頭の右・左・右・左の方式が一番になっている。
