リスクなしで
ソフトウェアを
より速く革新

開発環境は、ソフトウェア開発者がソフトウェアアプリケーションを作成および変更するためのセットアップまたは設定を指します。これはソフトウェア開発プロセスの重要な側面であり、開発者がコードの記述、テスト、デバッグを行うために必要なツールとリソースを提供します。開発環境は、プロジェクトのニーズと開発者の好みに合わせてカスタマイズされることが一般的です。個々の開発者のコンピュータ上のローカル環境またはクラウドベースの環境である場合もあります。重要なのは、開発者が本番環境とは切り離されたソフトウェアで作業できるスペースを提供し、ライブシステムへの意図しない影響のリスクを減らすことです。

テスト/QA（品質保証）環境

テスト/QA（品質保証）環境は、ソフトウェア開発プロセスの中で厳密なテストを実施するための特別な設定です。この環境では、バグの特定、機能の検証、指定された要件に準拠していることの確認などを行います。この環境は、ソフトウェア製品の品質と信頼性を維持するために重要です。

理想的には、テスト/QA環境は、ハードウェア、ソフトウェア、設定、およびデータに関して本番環境とできるだけ類似しています。この類似性により、ライブ環境で発生する可能性のある問題を特定するのに役立ちます。ただし、実際のユーザーや本番データに影響を及ぼさないようにするために、これは実際の運用には孤立しています。時には、環境に送信される第三者からのデータをシミュレーションする必要があります。

UAT環境

UAT環境（User Acceptance Testing environment）は、ソフトウェアアプリケーションのエンドユーザーが実際の世界や本番環境をシミュレートした環境でテストを実施するソフトウェア開発プロセスのステージです。これは、ソフトウェアがビジネス要件を満たし、エンドユーザーにとって期待どおりに機能することを検証するために行われます。

ステージング環境

ステージング環境の主な目的は、本番環境とできるだけ類似した状態をシミュレートすることです。これにより、以前のテストフェーズでは特定されなかった残余の問題を検出することができます。ステージング環境は、ハードウェア、ソフトウェア、設定、およびデータに関して本番環境と同様です。これには同じオペレーティングシステム、データベースシステム、ネットワーク構成、その他の関連するソフトウェアコンポーネントが含まれます。

UAT環境との違いは、ここでのスコープにシステムのすべての技術的側面が含まれていることです。テストは包括的であり、パフォーマンス、セキュリティ、負荷およびストレステストなどの側面をカバーしています。

Feature Flagsが人気を博する前は、ステージング環境は、ライブ環境でのユーザーエクスペリエンスや機能に影響を及ぼす可能性のある問題をキャッチする最後のチェックポイントとして見なされていました。

本番環境

ソフトウェア開発における本番環境とは、ソフトウェアアプリケーションが実際に展開され、エンドユーザーが利用できる最終的な設定です。これはソフトウェアが実世界で意図したタスクを実行する環境です。開発、ステージング、またはテスト環境とは異なり、本番環境にはライブデータが含まれ、実際のユーザーと対話します。それが作成された価値をソフトウェアが提供する場所です。この環境は、安定性、信頼性、パフォーマンスを最適化するために最適化されています。予想されるユーザーロードとワークフローの問題の想定内および想定外の処理に十分な強度を持つ必要があります。

これらの年月にわたり、「本番環境でのテスト」の概念は開発ライフサイクルにもたらされました。これは、全体のテストライフサイクルで必須のステップの1つになりました。これにより、ライブ環境でのユーザーエクスペリエンスや機能に影響を及ぼす可能性のある問題をキャッチする最後のチェックポイントが生まれました。

本番環境でのテスト

本番環境でのテストは、新機能、更新、または変更をエンドユーザーがアプリケーションとやり取りするライブ環境で直接テストするプロセスを指します。このアプローチは、開発やステージングなどの事前本番環境が実際の環境の複雑さや予測不可能性を完全に再現することは不可能であることを認識しています。本番環境でのテストの主な側面は次のとおりです。

実世界のフィードバック：本番環境でのテストは、実際の使用条件での変更のパフォーマンスについて即座のフィードバックを提供します。
実際の問題の特定：制御されたテスト環境では表面化しない問題、特定のユーザーの振る舞い、実世界の負荷シナリオ、他のシステムとの相互作用などを特定するのに役立ちます。
Feature Flags：Feature Flagsを使用して実装されることが多く、新しい機能をデプロイすることなく機能を有効または無効にすることができます。これにより、一部のユーザーで新機能をテストする方法が提供されます。
カナリアリリース：全面展開前に一部のユーザーに変更を段階的に展開し、影響とパフォーマンスを評価することができます。
監視と観測：リアルタイムで発生する問題を特定するために重要です。ログ記録、パフォーマンスモニタリング、ユーザーフィードバックのツールが必要です。
フォールバック機構：問題が発生した場合に変更を迅速に元に戻す能力は、ユーザーエクスペリエンスへの影響を最小限に抑えるために重要です。
ダークランチ：ユーザーに公開せずに機能を本番環境にリリースし、バックエンドの側面をテストすることができます。
A/Bテスト：2つのバージョンの機能を比較して、どちらが実際の環境でより良いパフォーマンスを発揮するかを確認します。

本番環境でのテストは、特にスピードの速いまたは常に進化している環境で貴重な戦略です。事前本番環境では再現不可能な実世界の洞察を提供し、より堅牢でユーザーフレンドリーなアプリケーションを作成するのに役立ちます。ただし、注意深い計画と強力な監視を伴う実行が必要です。これにより、ユーザーエクスペリエンスとシステムの安定性へのリスクを最小限に抑えることができます。

本番環境で制御されたテストにFeature Flagsを使用する方法

Feature Flagsとは？

Feature Flagsまたはフィーチャートグルとは、新しいコードをデプロイする必要なく、開発者が機能を有効または無効にするための技術です。この方法は、開発、ステージング、本番などのさまざまな環境で機能します。Feature Flagsは、アプリケーションの再デプロイや再起動なしでリアルタイムの機能制御を可能にします。制御されたテストにおいて従来の制御された環境ではなく、Feature Flagsを使用することには次のような数多くの利点があります：

リアルユーザーとの対話：実際のユーザーが新機能とのやり取り方法をテストできます。
リスクの軽減：機能を段階的に展開して、潜在的なリスクを軽減します。
正確なフィードバック：実世界の条件下でフィードバックを収集できます。

Feature Flagsを使用した実際の使用例：

Eコマース企業が、ユーザーの閲覧履歴や購買パターンに基づいて商品を提案する新しい推薦エンジン（またはアルゴリズム）を導入したいとします。この変更では、フロントエンドのコード、APIゲートウェイ、エンドポイントの変更は行われません。エンジニアが通常行う手順は次のとおりです：

孤立したコードファイル、クラス、または新しいマイクロサービスとして新しいエンジン（またはアルゴリズム）を作成します。
APIインターフェースの背後の内部コード関数を変更して新しい推薦エンジンを呼び出します。
バックエンドサービスの更新バージョンをデプロイします。

しかし、新しいアルゴリズムがうまく機能しないか、実世界のビジネスデータとのやり取りで重大なエラーが発生する可能性がある場合、慎重なアプローチとして新しい推薦エンジンを段階的に本番環境で展開することが重要です。

以下はいくつかの簡単な手順です：

古い推奨エンジンが呼び出されているコードを探します。次のようになるかもしれません：

public async Task<RecommendResult> CallRecommendationEngine(Parameters params){
  // some code
  return RecommendationEngineS2S(params);
}

"S2S" は古いアルゴリズムの名前で、RecommendationEngineS2S 関数を呼び出しています。

変数である機能フラグを用意します。この機能フラグ変数を使用して、古い推奨エンジンコードに if/else 条件を作成します。次のようになるかもしれません：

public async Task<RecommendResult> CallRecommendationEngine(Parameters params){
  // some code
  var newRecommdationFlag = _featureFlags.StringVariation("recommendation-engines");
  if(newRecommdationFlag  == "S2S"){
    return RecommendationEngineS2S(params);
  }
}

新しい推奨エンジンを呼び出すための関数を作成し、その関数の名前を RecommendationEngineDavinci にします。そして、"Else" の波括弧の下に新しい推奨エンジンを呼び出すコードを追加します。

public async Task<RecommendResult> CallRecommendationEngine(Parameters params){
  // some code
  var recommdationAlgoFlag = _featureFlags.StringVariation("recommendation-engines");
  if(recommdationAlgoFlag == "S2S"){
    return RecommendationEngineS2S(params);
  }
  else if(recommdationAlgoFlag == "Davinci"){
    return RecommendationEngineDavinci(params);
  }
}

コードの実行中、_featureFlags.StringVariation("recommendation-engines") の戻り値を制御する必要があります。サードパーティの機能フラグツールを使用している場合、これは簡単です。_featureFlags.StringVariation は、機能フラグ管理システム（UIを介して）での構成に基づいて適切な値を返す、サードパーティのSDKからの変数/パラメータです。

成熟した機能フラグツールを使用した本番でのテストの制御

機能展開とテストのリリースを区別することが重要です。展開とは新しいバイナリ、パッケージ、またはイメージがマシン、コンテナ、またはデバイスに転送されるプロセスを指します。新しいデプロイされたバージョンは本番環境で実行されますが、新機能はまだアクティブではありません。一方、リリースは、これらの新機能がアクティブ化されて一般に利用可能になるときに発生します。

この概念は、以下の実際のコード例（簡略化および以下で繰り返し表示）を使用して簡単に理解することができます。この例では、コード内の「Davinci」アルゴリズムは、_featureFlags.StringVariation("recommendation-engines") の戻り値が 'Davinci' と等しい場合のみ実行されます。このアプローチは**「リリースとの展開の切り離し」**と呼びます。


var recommdationAlgoFlag = _featureFlags.StringVariation("recommendation-engines");

if(recommdationAlgoFlag == "Davinci"){
    RecommendationEngineDavinci(params);
}

機能フラグの戻り値をどのように制御するか？以下はFeatBitのUIでの構成スクリーンショットです。機能フラグ "recommendation-engines" がオフになっている場合、"S2S" を返します（構成パネルの左側で構成）。機能フラグがオンで、ユーザーがQAグループにいる場合、"Davinci" を返します。それ以外の場合は、デフォルトで "S2S" を返します（構成パネルの右側で構成）。

どのようにして機能フラグの戻り値を制御するか？これはFeatBitのUI構成を使用して次の例で示されます。機能フラグ 'recommendation-engines' がオフになっている場合、左側の設定パネルで'S2S' を返します。機能フラグがオンでユーザーがQAグループにいる場合、'Davinci' を返します。それ以外の場合はデフォルトで 'S2S' を返します（右側の構成パネルで構成）。

パーセントの展開を使用して機能を段階的にリリースする

パーセントの展開を使用することで、機能を段階的にリリースし、問題やエラーが発生した場合にはすぐにロールバックできるようになります。この戦略は潜在的なリスクを最小限に抑えるのに役立ちます。以下の図は、FeatBitの機能フラグのUIパネルを使用して、制御された段階的なリリースの方法を示しています。これを行うには、単純に 'Davinci' の戻り値のパーセンテージを調整します。たとえば、「Davinci」推奨エンジンの戻り値のパーセンテージを20%に設定すると、リクエスト、ユーザー、クエリなどの20%がDavinciエンジンを使用します（コードでは機能フラグが "Davinci" を戻り値として取得）、残りの80%はデフォルトでS2Sエンジンを使用します（コードでは機能フラグが "S2S" を戻り値として取得）。

特定のユーザーグループをターゲットにする場合、特にリリースプロセスをより詳細に制御するために、『ターゲティングルール』を使用できます。この機能を使用すると、トラフィック分割戦略が特定のグループにのみ影響するようにカスタマイズできます。以下の図は、設定が行われており、新しいDavinciの推奨エンジンをカリフォルニア州の20%のユーザーにのみリリースするように設定されています。

この原則は柔軟であり、データベースの移行を含むさまざまなプログラミングシナリオに適用することができます。詳細な情報や例については、こちらの関連記事を参照してください。

特定のチームメンバーに機能をリリースする

上司が新しい機能のテストに参加したいと表明する場合、彼を個々のユーザーとして追加し、その機能にアクセスできるようにすることができます。次の図は、彼のユーザーアカウントを「個別ターゲティング」リストに追加することによって簡単に構成できる方法を示しています。

再利用可能なセグメンテーションの使用

多くの機能は一般公開前に本番でテストする必要があるため、多くの企業にはQA（品質保証）グループがあります。QAテスターはしばしばQAチームのメンバーと同じ人物です。そのため、'QA Group' というユーザーセグメントを作成できます。このセグメントでは、個々のメンバーを追加したり、グループの構成を決定するためのターゲティングルールを定義したりできます。以下のようになります：

その後、この再利用可能なセグメントを使用して、機能フラグのカスタマイズルールセクションでトラフィック分割戦略を簡単に構成できます。

機能リリースのタイミングをスケジュールする

ターゲットユーザーが異なるタイムゾーンにいる場合、テストプロセスを制御するために機能リリースのタイミングをスケジュールすることが重要です。以下の図は、新しい機能を西部アメリカの一般ユーザーの5%にリリースして、カリフォルニアにいるチームが営業時間中に問題に素早く対応できるようにする方法を示しています。

頑丈なモニタリングとワークフローでリスクを最小限に抑える

リリース中にエラーが検出された場合は、すぐに機能をロールバックすることが重要です。私たちは、よくDataDogやNew Relic Oneなどのインテリジェントな観測ツールとの機能フラグの使用と変更イベントとの統合を行います。この統合により、問題を迅速に検出し、アラートが発生したときにロールバックをトリガーすることができます。

フィーチャーユーザージャンルイベントは、フロントエンドアプリケーションで発生します。ユーザーが新機能を利用すると、使用イベントが観測ツールのリアルユーザーモニタリング（RUM）モジュールに送信されます。
Feature Flagsの変更イベントは、チーム（開発者、プロダクトマネージャー、マーケティングなど）によって行われる変更です。これらのイベントは、アプリケーションパフォーマンスモニタリング（APM）にデプロイメントイベントまたはアクティビティイベントとして送信されます。そして、インテリジェントなAPMオブザーバビリティツールは、問題のあるフィーチャーをオフに切り替えるためのコールバックアクションをトリガーすることがあります。

以下は、FeatBitがNew Relic One APMと統合する方法の例です。

FeatBitは、Feature Flagsの変更イベントを変更追跡に使用するデプロイメントイベントとしてNew Relicに送信します。
FeatBitは、特定のパフォーマンスメトリクスのしきい値に基づいて、トリガー（またはAPI）を使用してフラグのターゲティングをオンまたはオフに切り替えます。

たとえば、上の図は次のことを示しています：

Feature Flagsがオンになった後、Webトランザクションのエラーレートが顕著に増加した。
重大な問題が特定された。
その後、トリガーされたアラートに対応して、Feature Flagsが自動的にオフになった。
応答時間のピークとエラーレートが通常に戻った。
重大な問題が成功裏に解決された。

結論

このブログでは、ソフトウェア開発におけるさまざまなテスト環境の重要な役割を探求し、Feature Flagsの革新的な使用を強調しています。私たちは、ソフトウェアの機能性と品質を保証するために不可欠な「開発」、「テスト/QA」、「UAT」、「ステージング」、「本番」の各重要な段階をカバーしています。焦点は本番環境に移り、制御された設定では浮上しない問題を特定し、実世界のフィードバックを取得し、高品質なソフトウェアを提供するための貴重な戦略である「本番でのテスト」を強調しています。Feature Flagsは、フルデプロイメントせずに新機能をライブ環境でテストできる重要なツールとして浮上しています。この方法により、柔軟性が提供され、リスクが最小限に抑えられ、実際のユーザーの相互作用分析が可能となります。

私たちはこの実用的なeコマースの例でこれを実証し、Feature Flagsが新機能を安全に導入できる方法を示しています。DataDogやNew Relic OneなどのオブザーバビリティツールとFeature Flagsを統合することで、迅速なエラー検出と効率的なロールバックが実現され、全体的な安定性とユーザーエクスペリエンスが向上します。結論として、このブログは制御されたテストとFeature Flagsの重要性を強調し、高品質でしっかりしたソフトウェアの提供における重要性を強調しています。

リスクなしで ソフトウェアを より速く革新

Innovate Your Software Faster without Risk

安全なテスト環境の作成：制御されたテストにFeature Flagsを使用する方法

テスト環境の理解

開発環境