How do I offer a beta feature to select users? (rails)

We want to start letting our users help us test our feature changes before a wider release. Our rails app already has roles but I don't know how to we should go about implementing a beta feature without moving the whole app over.

Some issues I can't think of solutions to:

• A beta feature may require a database migration. How can you handle this when it could cause problems with the existing app?
• Changing templates and the css/sass will likely change it for existing features too.
• Changing the underlying model code could break existing controllers / interfaces that rely on it.

One solution (a bad option) is to code in the new feature and wrap it in logic that only shows/uses it if the user has the "beta" role. The problem with this is when you finally take it live, you could have a lot of unwinding/changing to do. This is both a waste of time and could introduce bugs.

Another solution is to run a separate "beta" branch of the app off a subdomain and route use开发者_运维百科rs with the beta role to it. The problem with this is that the complexity of ssl certificates, email links and other domain dependent issues make this a bit of a maintenance pain (though not as bad as the first solution).

How can I offer this most efficiently so as to minimize the additional work to maintain and then switch the beta to the full version?

I think the only reasonable chance of these kind of tests work without affecting the current application would be using a "staging" environment and really just redirect the beta users to that environment.

Compared to problems with domain related features it is really nothing compared to migrations/functionality problems.

On our company we do exactly that, but we don't have the beta users thing, but without an separated environment it will be pretty much inviable to keep new features from messing with current features.

For the features, just use different branches for those new features and create that "staging" environment from that branch, once the features have been tested you just merge them to HEAD and new feature is there :]

One possibility to consider: making destructive (i.e. one-way, non-reversible) changes to your model may be problematic for reasons beyond inhibiting your ability to provide this beta functionality. For example, it may difficult to backout from a change if you have a problem during the migration.

Instead, I would recommend looking at ways to only add to the model: add columns while leaving old columns in place for backward compatibility, version stored procedures if you're using them, etc. If you need to alter column data types, instead create a new column of the target data type, then have your migration also copy existing rows data from the old column to the new column in the new format. You can then perform your database migration in your test environment and confirm that both the old and new versions of the application continue to work with the database changes.

One potential way to serve up multiple versions of your application is to use an alternative respond_to format for your beta site. You could create a method in your ApplicationController to check if the user was in the beta. If true, you can override the request.format value and in your respond_to block have a "format.beta" type response.

The challenge with this approach is the controller logic. Without embedding some kind of switching logic within your controller methods, you won't have a way of altering the controller code path. This may not be a major problem, depending on how many controller changes you have.

(By the way, it looks like we have very similar names! :-) )

What I can think of is something like having a user_type column in your users table. so that you can flag them as beta users. (Even you can set this flag as default so that you dont need to change the existing code. All the new users who are creating will be beta users.)

For this i'm assuming

You are giving all the features to your beta users Beta users will be having the same functionality which will be having by normal user in future.

** Only advantage is that you can filter beta users as and when they are login. Upon that you can do something like allowing to login or not etc..

When you are switching to the full version just update beta users as normal users

I dont know how this is applicable to your scenario.

thanks

sameera

I personally don't think it's a bad idea to wrap the code with a check for a user having the beta role. It will be quite easy to search for all of the calls to, for example if current_user.authorized?(:beta) and the remove them entirely.

One thing I am thinking about doing is setting up a beta "staging" environment that is actually the production environment. The idea would be to have beta.mydomain.com and then send users there that want to get features early. Basically, it would just be a branch that gets deployed to the beta site which is live.