スタンドアロン（またはネイティブ）アプリと LaunchDarkly によるカナリアリリースの課題

概要：

スタンドアロンアプリ開発（Webアプリではなく）にて LaunchDarkly によるカナリアリリースを行っていますが、ある問題が発生しています。いくつか策はありますが、一般論や似たような事例があるはずで、それを知りたいですが、手詰まりな状態です。

スタンドアロンアプリにおいて、LaunchDarkly の短期の機能フラグを以下のメリットのために使います。

メリット：

流れ：

Web アプリでは問題ないですが、スタンドアロンアプリの場合、以下の問題が生じます。

例：

最後のステップ「フラグで全ユーザーに開放する」にて、Ver 1.x.x を使うユーザーにも機能が開放されることになります。Ver 1.x.x の時点で既に品質がよければ問題ありませんが、そうでなければ、品質が悪い機能が提供されることになります。

問題：

この問題は、以下の問題に類似しており、”古いバージョンを使うことによる問題点” の一種と思われます

強制アップデートにすれば、スタンドアロンでもほぼ Web アプリと同様に最新版のみを提供できることになり、上記の問題は発生しません。ただし、強制アップデートを使えない事情があるため、この案は採用できないと仮定します。

ベータテストのためのフラグ beta-flag と、カナリアリリースのためのフラグ feature-flag を用意します。

流れ：

一部ユーザーのみに提供するため、beta-flag がONであれば使える状態でリリースする
全ユーザーに公開しても良い段階にする
全ユーザーに提供するため、feature-flag がONであれば使える状態でリリースする
- このとき、beta-flag は削除するなどで OFF にする

冒頭のメリットについて

ベータテスト：リリース前に、一部ユーザーなどの一部のみに開放する
- → ベータテストのためのフラグを設ける
カナリアリリース：異なるバージョンのアプリをデプロイしなくても、機能を提供できる
- → △ カナリアリリースのためのフラグを設けたバージョンをリリースする必要がある

フラグは、boolean だけではなく、文字列や JSON も設定可能なことから、3 種類の値を持つフラグを設けます。

スタンドアロンアプリ側で、フラグがバージョンの値であるときは、自身のバージョンの値と比較して ON、OFF かどうかを判断します。

流れ：

冒頭のメリットすべて得られるため、これが理想に思います。

言葉のメモ

フラグ
- 短期的なフラグと、永続的なフラグ
リリース管理
- カナリアリリース：一部のユーザーのみが利用できるようにリリースすること
  - リング展開
    - パーセンテージベースの展開
  - ベータテスト：全ての人にリリースする前に、顧客のフィードバックを得る

miso_soup3 Blog