たとえば、ユーザーは、全体的なユーザー ベースの割合 (10%) のみに基づいている可能性があります。ロールアウトはカスタマイズ可能 (構成可能) であり、任意の数の機能をサポートする必要があります。また、ロールアウトを特定のユーザー ロールまたは特権 (ACL) に関連付けると便利です。
では、本質的に、適切に拡張できるアーキテクチャとはどのようなものでしょうか?
言語にとらわれない部分については、疑似コード、一般的な概念やアイデア、または好みの言語のスニペットを提供して、要点を理解することができます。
例やチュートリアルへのリンクは大歓迎です。
私が推奨するのは、新機能を入手しようとしている人々にとって、彼らがアクセスしているサイトは、機能が公開された後に誰もがアクセスするサイトにできるだけ近いものにすることです.
言い換えれば、たとえば、ボタンを表示するかどうかを決定する条件付きロジックを、このベータ期間中にのみ存在する場合は、ページに配置しません。むしろ、ログイン時に、この人がベータ参加者であるかどうかを判断します (その判断はランダムである可能性があり、その役割を参照する可能性があります)。彼らが参加者である場合、バージョン管理ブランチから展開された個別に展開されたサイトにリダイレクトされます。
ロールアウトが完了すると、ブランチがマージされ、全員が新機能を確認できます。
こうすれば、パブリック ベータ ユーザーが見ているコードベースが最終的なリリース コードベースと異なる (何かを壊す可能性がある) ことを心配する必要はありません。
私の最後の仕事では、ロード バランサーと現在のリビジョン Cookie を使用してこれを達成しました。
ロード バランサーは、ユーザーが使用していたインスタンスのリビジョン番号を識別する Cookie を設定しました。その Cookie が既に存在する場合、ロード バランサーはそのリクエストを、対応するリビジョンで実行中のインスタンスに送信します。新しいリビジョンをデプロイすると、リビジョンが実行されなくなるか、ユーザーがブラウザーを閉じるまで、ロード バランサーは既存のリビジョン Cookie を含むトラフィックを元のリビジョンに送信し続けました。新しいトラフィックは、新しく展開されたリビジョンに送信されます。これにより、既存のユーザーが古いリビジョンで実行し続けている間に、変更を少しテストすることができました。また、その Cookie を手動で設定して、新しいトラフィックを生成する前に、運用環境で内部的に新しいリビジョンをテストすることもできます。
ただし、そのセットアップは後方互換性のないデータベースの変更をサポートしていません。ユーザーの一部を 1 つの db スキーマに、一部を別の db スキーマに配置し、両方に書き込みを行い、新しいリビジョンが適切であると判断した後でそれらの書き込みを何らかの方法でマージできる場合、それを行う方法はほとんどありません。 . つまり、それは可能ですが、スキーマの変更が正確に何であるか、およびそれらがアプリにどのように影響するかに大きく依存するため、展開時に信頼できる、不可知な方法でそれを行うことはできません. 私たちにとっては、一般的に後方互換性のないスキーマ変更を行わないようにしました。本当に必要な場合は、破壊的な部分 (列またはテーブルの削除) を後のリビジョンに延期して、スキーマを移行し、現在のユーザーに悪影響を与えずに両方のバージョンを実行できるようにします。
ランダムな選択プロセスでは、ログインに成功したときにベータ テストに参加するかどうかを各顧客に尋ねるというコンセプトが気に入っています。必要なユーザー数または希望するユーザー数の合計に達したら、尋ねるのをやめます。データベースでは、ユーザーをリダイレクトするサーバーを保存し、ログイン時に各ユーザーを正しい場所に移動する標準スクリプトを実行する傾向があります。
アプリ開発は数か月前に設計し、既存のスキーマの変更を避けます。その理由は非常に明白です。もちろん、これが常に可能であるとは限りません。そのため、このような変更がある場合は、変更が記述されたときに常に完全に文書化し、できるだけ早くこのフィールドの移行を計画しています。このようにして、どのような変更が行われるかについての戦闘計画を立て、可能な限り最善の解決策を講じることができます。残念ながら、これは状況に応じて変更されます。
私たちは常に複数の環境を実行しており、一般的には本番環境、開発環境、およびベータ版があります。これは、私たちがお金に等しい生産サービスを台無しにしないことを意味し、最適化時にコードを壊してサービスをオフラインにする人がいないことを意味します。
開発ではバージョン監視に GIT を使用していますが、ユーザーはこれを目にすることはありません。また、ライブデータに対して独自のデータベースを使用します。
ベータ版では、一般的に特定のユーザー データを移行しますが、最近、データベース全体を複製し、ベータ版を開始する特定の日付を計画することで、より良いエクスペリエンスが得られました。これにより、ユーザーはベータ版をオプトアウトし、他のユーザーはオプトインできます。このオプションをサポートするために必要な変更は最小限です。通常、1 日 1 回、2 つのデータベース間で新しいデータを移行します。新しいオプトインとオプトアウトは、データが他のプラットフォームに移行された時点からのみ有効になります。
また、既存の本番データベースを使用して、独自のテーブルで動作するいくつかの新しい機能をベータ テストするために小規模で成功しているため、同じライブ データベースを使用してデータに関して何を行っているかによっては、適切なオプションになる可能性があります。
これがあなたのお役に立てば幸いです...テスト仲間との幸運を祈ります。
Google ウェブサイト オプティマイザーはまさにあなたが探しているもののようです。