6

より広範なリリースの前に、ユーザーに機能の変更をテストしてもらいたいと考えています。Rails アプリには既に役割がありますが、アプリ全体を移動せずにベータ機能を実装する方法がわかりません。

解決策が思いつかないいくつかの問題：

  • ベータ機能では、データベースの移行が必要になる場合があります。既存のアプリで問題が発生する可能性がある場合、これをどのように処理できますか?
  • テンプレートと css/sass を変更すると、既存の機能も変更される可能性があります。
  • 基になるモデル コードを変更すると、それに依存する既存のコントローラー/インターフェイスが壊れる可能性があります。

1 つの解決策 (悪いオプション) は、新しい機能をコーディングして、ユーザーが「ベータ」ロールを持っている場合にのみそれを表示/使用するロジックでラップすることです。これに関する問題は、最終的にライブにするときに、多くの巻き戻し/変更を行う必要がある可能性があることです. これは時間の無駄であり、バグを引き起こす可能性があります。

もう 1 つの解決策は、アプリの別の「ベータ」ブランチをサブドメインから実行し、ベータ ロールを持つユーザーをそこにルーティングすることです。これに関する問題は、ssl 証明書、電子メール リンク、およびその他のドメインに依存する問題の複雑さにより、これが少しメンテナンスの苦痛になることです (ただし、最初の解決策ほど悪くはありません)。

維持するための追加作業を最小限に抑え、ベータ版を完全版に切り替えるために、これを最も効率的に提供するにはどうすればよいですか?

4

5 に答える 5

1

この種のテストが現在のアプリケーションに影響を与えずに機能する唯一の合理的な可能性は、「ステージング」環境を使用し、実際にベータ ユーザーをその環境にリダイレクトすることだと思います。

ドメイン関連の機能の問題と比較すると、移行/機能の問題と比較すると、実際には何もありません。

私たちの会社ではまさにそれを行っていますが、ベータユーザーのことはありませんが、分離された環境がなければ、新しい機能が現在の機能を台無しにしないようにすることはほとんど避けられません.

機能については、それらの新機能に異なるブランチを使用し、そのブランチからその「ステージング」環境を作成するだけです。機能がテストされたら、それらをHEADにマージするだけで、新しい機能があります:]

于 2010-08-31T18:38:39.217 に答える
0

個人的には、ベータ版の役割を持つユーザーのチェックでコードをラップするのは悪い考えではないと思います。たとえば、へのすべての呼び出しを検索し、if current_user.authorized?(:beta)それらを完全に削除するのは非常に簡単です。

于 2010-08-31T17:01:30.590 に答える
0

私が考えることができるのは、users テーブルに user_type 列があるようなものです。ベータ ユーザーとしてフラグを立てることができます。(既存のコードを変更する必要がないように、このフラグをデフォルトとして設定することもできます。作成しているすべての新しいユーザーはベータ ユーザーになります。)

このために、私は仮定しています

ベータ ユーザーにすべての機能を提供しています。ベータ ユーザーは、将来、通常のユーザーが持つ機能と同じ機能を持ちます。

** 唯一の利点は、ベータ ユーザーがログインしているときにフィルタリングできることです。その上で、ログインを許可するかどうかなどを行うことができます..

フルバージョンに切り替えるときは、ベータユーザーを通常のユーザーとして更新するだけです

これがあなたのシナリオにどのように適用されるかわかりません。

ありがとう

同時代

于 2010-08-30T13:02:09.453 に答える
0

考慮すべき 1 つの可能性: モデルに破壊的な (つまり、一方向で元に戻せない) 変更を加えることは、このベータ機能を提供する能力を阻害する以上の理由で問題になる可能性があります。たとえば、移行中に問題が発生した場合、変更を取り消すことが難しい場合があります。

代わりに、モデルにのみ追加する方法を検討することをお勧めします。下位互換性のために古い列を残して列を追加し、使用している場合はストアド プロシージャをバージョン化するなどです。列のデータ型を変更する必要がある場合は、代わりに作成します。ターゲット データ型の新しい列を作成した後、移行で既存の行データも古い列から新しい列に新しい形式でコピーします。次に、テスト環境でデータベースの移行を実行し、アプリケーションの古いバージョンと新しいバージョンの両方がデータベースの変更で引き続き機能することを確認できます。

アプリケーションの複数のバージョンを提供する 1 つの考えられる方法は、ベータ サイトに代替の Respond_to 形式を使用することです。ApplicationController にメソッドを作成して、ユーザーがベータ版かどうかを確認できます。true の場合、request.format 値をオーバーライドでき、respond_to ブロックに「format.beta」タイプの応答を含めることができます。

このアプローチの課題は、コントローラーのロジックです。コントローラー メソッド内になんらかの切り替えロジックを埋め込まなければ、コントローラーのコード パスを変更する方法がありません。コントローラーの変更回数によっては、これは大きな問題ではない場合があります。

(ちなみに、私たちは非常に似た名前を持っているようです! :-) )

于 2010-08-30T22:39:08.737 に答える
0

私が考えていることの 1 つは、実際には運用環境であるベータ版の「ステージング」環境をセットアップすることです。beta.mydomain.com を用意して、機能を早期に入手したいユーザーをそこに送り込むという考えです。基本的には、ライブのベータ サイトに展開されるブランチにすぎません。

于 2010-09-03T04:50:01.977 に答える