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 users 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?
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! 🙂 )