機能フラグ
フィーチャー フラグを使用して機能を段階的に公開する方法。
Ian Buchannan
プリンシパル ソリューション エンジニア
開発中に機能をアプリケーションに継続的に統合する予定の場合は、フィーチャー フラグの検討をお勧めします。最終的には、フィーチャーの切り替え、その非表示、無効/有効化が必要になるでしょう。また、どのフィーチャーが優れているかを確認するために、さまざまなフィーチャーのバリエーションをユーザーに公開できます。「トグル」、「ビット」、「フリッパー」、または「スイッチ」とも呼ばれるフィーチャー フラグでは、この他にもさまざまなことが可能です。
フィーチャー フラグとは何か
機能フラグ (一般に機能トグルとも呼ばれる) は、新しいコードをデプロイすることなく実行時に選択機能のオンとオフを切り替える、ソフトウェア エンジニアリング手法です。これによってチームは追加のコードをプッシュすることなく変更を加えられて、機能のライフサイクル全体にわたって実験の制御を強化できます。このため、機能フラグはアジャイル管理スタイルや CI/CD 環境にとって非常に有用な新しい各種ワークフローを可能にします。
開発中、ソフトウェア エンジニアは目的のコード パスをフィーチャー フラグにラップします。以下は、Javascript で記述した基本的なフィーチャー フラグの例です。
if(featureFlags[‘new-cool-feature’] == true){
renderNewCoolFeature();
} このコードは、「new-cool-feature」が有効になっているかどうかを確認する簡単なステートメントを示しています。フラグ データの管理や新しいロジック パスの埋め込みと削除に役立つ高度なフレームワークやツールであっても、フィーチャー フラグは本質的に単なる「IF ステートメント」です。したがって、このバイナリ スイッチはすべてのシノニムに共通しているものです。
ソリューションを見る
Open DevOps によるソフトウェアの構築と運用
関連資料
トランク ベース開発の詳細
機能フラグのメリット
基本レベルでは、フィーチャー フラグを使用するとコードを休止状態で本番環境にコミットしてデプロイし、後でアクティブ化できます。これによって、チームは最終製品のユーザー エクスペリエンスをより詳細に制御できます。開発チームは、新しいコードをいつどのユーザーに配信するかを選択できます。
フィーチャー機能の検証
開発者はフィーチャー フラグを活用すれば、新しい製品フィーチャーの「ソフト ロールアウト」を実行できます。新しいフィーチャーは、想定しているリリースの一環としてフィーチャー トグルをすぐに統合することで構築できます。フィーチャー フラグはデフォルトで「オフ」に設定できるため、コードがデプロイされると新しいフィーチャーは本番環境中には休止状態になり、フィーチャー切り替えが明示的にアクティブになるまで無効になります。次に、チームがフィーチャー フラグをオンにするタイミングを選択します。これによってコードがアクティブになり、チームは QA を実行して想定どおり動作することを確認できます。チームがこのプロセスで課題を発見した場合は、すぐにフィーチャー フラグをオフにして新しいコードを無効にし、ユーザーが課題に直面することを最小限に抑えられます。
リスクの最小化
上述したソフト ロールアウトの考え方に基づいて、勤勉なチームはシステムの監視と指標を組み合わせてフィーチャー フラグを活用し、観察できる断続的な課題に対処できます。たとえば、アプリケーションでトラフィックが急増して監視システムから課題の増加が報告された場合、チームはフィーチャー フラグを使用してパフォーマンスの低いフィーチャーを無効にできます。
システム動作を中断することなく変更を加える
フィーチャー フラグを使用すると、複雑なコードの統合やデプロイメント シナリオを最小限に抑えられます。複雑な新機能や機密性の高いリファクタリング作業は、リポジトリのメイン プロダクション ブランチに統合するのが難しい場合があります。複数の開発者がコードベースの重複部分で作業する場合は、さらに複雑になります。
既知の安定したコードが残っている場合、新たな変更を分離するためにフィーチャー フラグを使用することができます。これにより、開発者は、フィーチャーの切り替えの背後でリポジトリの main ブランチに頻繁にコミットすることで、フィーチャー ブランチの長時間の実行を回避することができます。新しいコードの準備が整うと、中断を伴う共同マージとデプロイのシナリオが不要になります。チームはフィーチャー フラグを切り替えて、新しいシステムを有効にすることができます。
フィーチャー フラグの使用例
フィーチャー フラグの新規ユーティリティは、勤勉なチームにさまざまなクリエイティブなユース ケースをもたらします。次の例では、アジャイル環境におけるフィーチャー フラグの一般的なアプリケーションをいくつか取り上げています。
製品テスト
フィーチャー フラグを使用して、新しい製品フィーチャーを徐々にリリースできます。提案された新規フィーチャーがユーザーによって採用された場合は、投資収益率に値するかどうかは率直に言って不明です。チームは新しい製品フィーチャーかその一部のアイデアをフィーチャー フラグでリリースしてそれをユーザーのサブセットにデプロイし、フィードバックを収集できます。ユーザーのサブセットは、ベータ テストとレビューに満足したことを率直に述べているパワー ユーザーである場合もあります。新製品のアイデアがヒットすることが判明した場合、開発チームはユーザー ベースをさらに拡大してフィーチャー フラグをロールアウトできます。しかし、新製品のアイデアが失敗に終わっても、フィーチャー フラグを簡単に無効化して後でコードベースから削除できます。
実験を行う
実験または A/B テストは、主要なフィーチャー フラグの例です。最も単純な形では、フィーチャー フラグはフィーチャーの「オン」と「オフ」状態の切り替えとして機能します。高度なフィーチャー フラグでは複数のフラグを一度に利用して、ユーザーのサブセットに対してそれぞれ異なるエクスペリエンスをアクティブにします。たとえば、ユーザーベースを 3 つに分割するとします。分割したそれぞれが独自のフラグとユーザー エクスペリエンスを受け取ります。次に、これらの 3 つのフラグのパフォーマンスを互いに測定して、最終的なコミット バージョンを判断できます。
移行
アプリケーションには、依存するアプリケーション コードの変更を必要とするデータ移行が必要になる場合があります。これらのシナリオは、機密性の高いマルチフェーズのデプロイ タスクです。データベース フィールドは、アプリケーション データベース内で変更、削除、または追加できます。このデータベース変更に対してアプリケーション コードが準備されていないと、障害やエラーが発生します。この場合は、データベース変更とアプリケーション コードの間でデプロイの調整が必要になります。
フィーチャー フラグはチームがフィーチャー フラグでアプリケーションの変更を事前に準備できるため、このシナリオの複雑さを軽減できます。チームがデータベースに変更を加えたら、アプリケーション コードに合わせてフィーチャー フラグをすぐに切り替えられます。これによって、新しいアプリケーション コードのデプロイを待機したり、デプロイに失敗してアプリケーションとデータベースの同期が解除されたりするようなリスクや遅延を解消できます。
カナリアの開始
この場面におけるカナリアとは、炭鉱労働者が一酸化炭素を検出するためにカナリアを炭鉱に持ち込んだ古い慣行を表しています。鳥類は代謝率が高く呼吸が速いため、鉱山労働者より先に一酸化炭素中毒になるのです。
ソフトウェア開発におけるカナリアの開始とは、新しいフィーチャーやコードの変更がユーザーの小さなサブセットをデプロイして、その動作を監視してからユーザー セット全体にリリースすることを表します。新しいフィーチャーにエラーや障害がある場合は自動でロールバックされます。フィーチャー フラグは、対象者プールを制限してフィーチャーを簡単にオフにできるため、このプロセスには不可欠です。
システム停止
フィーチャー フラグは、システム停止ツールとしても使用できます。Web アプリケーションはフィーチャー フラグを使用して、保守やダウンタイムのために Web サイト全体を「オフ」にする場合があります。フィーチャー フラグはコードベース全体に適用して機密性の高いトランザクションをプッシュし、エンド ユーザーに停止しているコンテンツを表示できます。これは、機密性の高いデプロイを行う場合や、予期しない問題が見つかって早急な解決が必要な場合などに非常に役立ちます。これによって、チームは必要と判断された場合に停止を確実に制御する能力を取得します。
継続的デプロイ
機能フラグは、真の継続的なデプロイ システムを構築するための不可欠なコンポーネントとして使用できます。継続的デプロイとは自動化されたパイプラインであり、これによって開発者から新しいコードを受け取って本番エンド ユーザーに自動でデプロイできます。継続的デプロイは自動テストのレイヤーに依存します。このレイヤーでは、新しいコードがパイプラインを通過するときに該当する仕様に対して想定どおりに動作することを検証します。
フィーチャー フラグは、コード変更をフィーチャーのユーザーへの公開と分離することによって、デプロイを安全に継続できます。新しいコードは自動でマージして本番環境にデプロイし、フィーチャー フラグの背後に待機させられます。継続的なデプロイ システムでは、ユーザーの動作とトラフィックを監視して、その後フィーチャー フラグを自動でアクティブにできます。ただし、この継続的なデプロイ システムでは、新しいフィーチャー フラグ コードを監視して想定どおりに動作しているかを確認し、動作していない場合はロールバックもできます。
フィーチャー ブランチとフィーチャー フラグの比較
フィーチャー ブランチとフィーチャー フラグは名前が類似していますが、その内容は大きく異なります。フィーチャー ブランチはワークフロー パターンで、Git ソース管理リポジトリに関連しています。開発者は、新しい製品フィーチャーの開始時には、main ブランチから外れて、新しいフィーチャーのすべてのコードを含む、対応する Git ブランチを新たに作成します。新しいフィーチャーが完成したら、フィーチャー ブランチを main にマージしてデプロイします。フィーチャー ブランチは、フィーチャー フラグとは区別されるスタンドアロンです。
フィーチャー フラグは、フィーチャ ブランチと併用できます。フィーチャー フラグを作成するには、開発者がフィーチャー ブランチを作成して、新しいフィーチャー フラグ コードをフィーチャー ブランチにコミットします。導入するとフィーチャー ブランチはマージされてデプロイされ、フィーチャー フラグが本番環境でもアクセス可能になります。
フィーチャー ブランチの開発では、プロジェクトの存続期間が長くなるか、main ブランチから外れた、コミットの多いものになる可能性があります。開発者は、マージする準備が整ったときに競合を最小限に抑えられるように、フィーチャー ブランチが継続的に更新されるようにする必要があります。フィーチャー ブランチを継続的に更新させるには、開発者の負担が増加しますが、フィーチャー ブランチをマージする段階では、矛盾を最小限に抑えられます。フィーチャー フラグは、このシナリオの修正に使用できます。存続期間の長いフィーチャー ブランチを作成し、新しいフィーチャーの準備が整ったときに大規模なマージを実行するのではなく、フィーチャー フラグを作成してすぐに main にマージすることができます。
フィーチャー フラグの実装方法
フィーチャー フラグの実装にはさまざまなパスがあり、論理上の考慮事項やさまざまな物流上の考慮事項や投資収益率によって異なります。どのパスを選択するかは、チームのニーズと組織の目標によって異なります。
フィーチャー フラグには、正しく機能するために対応する必要のあるインフラストラクチャの依存関係がいくつかあります。チームがフィーチャー フラグの使用規模を拡大してフラグのオン/オフの切り替えがビジネス上の意思決定になると、フラグについて権限のあるデータ ストアと管理のメカニズムを持つことが重要になります。サードパーティのフィーチャー フラグ サービスの多くで、このデータ ストアの依存関係が生じています。
ほとんどの場合は、サードパーティのホスト型フィーチャー フラグ サービスが最適なソリューションになります。膨大なロジスティクスを処理して統合を容易にするライブラリを提供し、インストール プロセスをスピードアップします。これによって、チームはインフラストラクチャ管理ではなく本題の業務に集中できます。ただし、チームがサードパーティに関するセキュリティ上の懸念事項を抱えている場合は、セキュリティ フラグ バックエンドを実装することをお勧めします。
これとは別に、エンジニアは、サービスからフラグの状態を取得してフラグのついたコンテンツをアクティブ化するための新しいコード ロジックを組み込む必要があります。これにはアクティブ化の前にコードのマージとフラグ コードのデプロイが必要です。ほとんどのフィーチャー フラグは一時的なものなので、不要になったフィーチャー フラグは必ず削除してください。
結論
フィーチャー フラグはアジャイル開発をサポートする強力な手段で、クリエイティブな多数の活用方法があります。フィーチャー フラグは継続的なデプロイと Git バージョン管理を補完するもので、総合的にはチームはコードベース、デプロイ、エンド ユーザー エクスペリエンスをより詳細に制御できるようになります。
DevOps 機能フラグのチュートリアルを必ずご確認ください。チュートリアルでは Open DevOps ツールチェーンでのベスト プラクティスを明示しています。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
DevOps コミュニティ
ブログを読む
