フィーチャーフラグAPIの標準化を目指す「OpenFeature」がCloud Native Computing Foundationのインキュベーティングプロジェクトに昇格

KubernetesやContainerdなどクラウドネイティブ関連ソフトウェアの開発をホストするなど、クラウドネイティブの普及や推進のための団体「Cloud Native Computing Foundation」（CNCF）は、フィーチャーフラグAPIの標準化を目指す「OpenFeature」がこれまでのサンドボックスプロジェクトから、新たにインキュベーティングプロジェクトに昇格したことを発表しました。

The CNCF TOC has voted to accept OpenFeature as a CNCF incubating project!

Congratulations @OpenFeature https://t.co/sQSq4o2qEV pic.twitter.com/XFgws17IOm

— CNCF (@CloudNativeFdn) December 19, 2023

サンドボックスはCNCFの中で実験的なプロジェクトという位置づけです。インキュベーティングに昇格することは、プロジェクトが本格的な育成時期に入ることを意味します。

フィーチャーフラグはコードを変更せずに機能を変更する

フィーチャーフラグとは、ソフトウェアの機能の追加や変更をするために仕込まれるフラグです。これによりソフトウェアのリリースのタイミングと機能の追加や変更のタイミングを切り離すことができるようになります。

具体的には、新機能を組み込んだソフトウェアを本番環境にデプロイしたとしても、新機能のフィーチャーフラグをオフにしておくことで新機能の提供タイミングを管理者がコントロールできるようになります。

そして、例えば少数のユーザーだけに試験的に新機能を有効にして動作確認をし、確認後に全ユーザーに開放することで安全に新機能を試せるようになります。

万が一新機能に問題があったときでもフィーチャーフラグをオフにするだけで、ソフトウェア全体を旧バージョンにロールバックする手間も発生しません。次のリリースで修正し、またフィーチャーフラグを使って試せばよいのです。

あるいは機能変更のフィーチャーフラグを用意し、一部のユーザーにだけ機能変更を有効にして反応を確認し、評判が悪いようであれば機能変更を見直すことも可能になります。

このようにフィーチャーフラグの利用は、ソフトウェアの安全なリリースや迅速な改善に役立つ機能として、多くのソフトウェアで採用されようとしているのです。

フィーチャーフラグを管理するための標準API

しかしフィーチャーフラグを活用したソフトウェアが大型化し、多くのフィーチャーフラグが設定され、さらにフィーチャーフラグが何種類ものソフトウェアで実装されるようになると、どのフィーチャーフラグがオンになっているのか、どのフィーチャーフラグで試験しているのかなどが分からなくならないように、フィーチャーフラグ全体を1つのダッシュボードなどで管理する必要が出てきます。

OpenFeatureは、このフィーチャーフラグを管理するためのAPIの標準仕様を策定し、C#やJava、Go、JavaScriptやPHP、Python、Rubyなどのさまざまなプログラミング言語に対応したSDKを提供するプロジェクトです。

ソフトウェア開発時に組み込んだフィーチャーフラグをこのOpenFeatureのAPI経由で管理できるようにしておけば、OpenFeatureのAPIに対応したフィーチャーフラグ管理ダッシュボードで一元管理できるようになります。

これにより開発者はフィーチャーフラグの実装を特定のベンダや管理ソフトウェアなどに依存することなくできるようになるわけです。

OpenFeatureは、CNCFのインキュベーティングプロジェクトに昇格したことでフィーチャーフラグ管理APIの事実上の標準としての地位を大きく固めたことになります。

2024年3月追記

フロントエンドでフィーチャーフラグを実現するためのSDKもリリースされました。

• フロントエンドにおけるフィーチャーフラグ標準化のための「OpenFeature Web SDK v1」がリリース。CNCFから