多くのA / Bテストを行うコードベースの良いパターンは何でしょうか？
私は多くのA/Bテストを行う傾向がある環境で開発しています。 A/Bテストコードがコードベースでどのように管理されているかを他の人から知りたいと思いますか？
A/Bテストコードと制御コード（既存の機能）を混ぜますか？そうする場合、コードベースが保守不能になるのをどのように確実にしますか？
コントロールコードとテストコードを「分岐」するのに役立つ特定の設計パターンはありますか？
私の現在の場所では、基本的にフロントエンドエンジニアに、各実験の「全体」のフロントエンドフォルダーをコピーし続け、変更を加えるように依頼しています。
長所：
- フロントエンド制御コードとテストを分離します。テストコードにバグがある場合、制御コードは影響を受けません。コードをリリースせずにA/Bテストをオフにすることができます。
- このパターンで意欲的なレイアウト変更を行うことができます。
短所：
- 変更管理はより困難になります。 5つの同時A/Bテストを実行していて、制御コードに変更を加える場合は、すべてのA/Bテストで制御コードに加えられた変更を確実に取得する必要があります。
リリースごとに多くの機能をデプロイし、本番環境でそれらをテストするときに、4つのことが私を大いに助けました。
- 機能フラグ。
- ホワイトリスト。
- ルーティング制御。
- 詳細なログ。
機能フラグにより、制御された時間の機能を有効にできます。 1日の特定の部分、または1つの地域のみ。これにより、顧客にとってうまくいかなかった変更をすばやく「取り消す」ことができました。
ホワイトリストにより、特定の明確に定義された顧客のセットに対してのみ機能を有効にすることができました。これにより、機能の明示的な「ベータテスター」を作成し、リストをすばやく展開または縮小できます。
ルーティング制御により、たとえばトラフィックの2％を機能セットAのサーバーに、3％を機能セットBのサーバーに、残りを最新の安定版に転送します。
詳細なログにより、どのログ行がどのサーバー、どのリリースに属しているかなどを知ることができました。すべての行には、特定の機能が有効/無効になっている行を簡単にグループ化し、分析/比較（Splunkを使用）するのに十分な情報が含まれていました。
お役に立てれば。