3

ベータ版機能を Web サイト ユーザーの小さなサブセットに展開するプラットフォームが必要です。これを行い、あなたの提案を探すためのベストプラクティスが何であるかはわかりません。

オプション 1 : 最初に検討したオプションは、ライブ アプリケーションをミラーリングする非運用環境を作成することでした。その後、最新の機能を試用できる新しいベータ DNS をユーザーに提供できます。このアプローチの欠点は、保守性と信頼性です。ユーザー エクスペリエンスが運用環境と一貫していることを確認するには、運用環境のデータをベータ データベースに更新する必要があります。このベータ環境は本番環境以外のインフラストラクチャにあるため、継続的なビルドなどの結果として停止する可能性が高くなります。

オプション 2: 追加のサーバーを運用環境にデプロイし、ベータ サブドメインを使用してユーザーをサイトに誘導します。古いデータは既存の実稼働環境と同じソースを指している可能性があるため、ここでは問題はありません。欠点は、アプリケーションの安定性と信頼性を維持するためにライブ本番環境へのリリースの頻度が低くなり、本番サポート チームが維持する余分なノードになることです。

オプション 3: メイン コード ブランチの一部としてベータ機能を展開し、特定のユーザーにベータ機能を表示するロジックをコードに含めます。このアプローチでは、ベータ版の変更を安定したコードに実装する必要があります。リリースの頻度が低くなり、既存のコード ベースの安定性に影響を与えることなくテストできる変更の種類の柔軟性が低下します。

どのように進めるべきかについて、過去の経験から何か提案はありますか?

ありがとう

4

1 に答える 1

1

オプション 2) を使用します。ベータ コードを本番コードから可能な限り分離したいと考えています。このようにして、最悪の事態が発生し、ベータ コードがサーバーをクラッシュさせた場合、ベータ ユーザーは本番サーバーにフェールオーバーするだけです。

1) ベータ環境が不安定すぎると、ユーザーは単純にそれを使用しなくなります。3) を使用すると、製品コードが汚染されるリスクがあります。

この種のことに関する私の経験のほとんどは、新しい「サーバー」を取得するのが新しい EC2 インスタンスを取得するのと同じくらい簡単な Amazon AWS でのものです。新しいサーバーをセットアップするのにそれほど費用はかからないと思います。

于 2013-04-15T16:49:22.713 に答える