¿Cómo ofrezco una función beta para seleccionar usuarios? (rieles)

Question

Queremos empezar a permitir que nuestros usuarios nos ayuden a probar nuestros cambios de funciones antes de una versión más amplia. Nuestra aplicación de rieles ya tiene roles, pero no sé cómo debemos implementar una función beta sin mover toda la aplicación.

Algunas cuestiones que no puedo pensar en soluciones a:

• Una característica beta pueden requerir una migración de base de datos. ¿Cómo puede manejar esto cuando podría causar problemas con la aplicación existente?
• Cambiando plantillas y css/sass probablemente también lo cambie por las características existentes.
• Cambiar el código del modelo subyacente podría romper los controladores/interfaces existentes que dependen de él.

Una solución (una mala opción) es codificar en la nueva característica y envolverla en lógica que solo la muestra/usa si el usuario tiene el rol "beta". El problema con esto es cuando finalmente lo tomas en vivo, puedes tener que desenrollar/cambiar mucho para hacerlo. Esto es una pérdida de tiempo y podría introducir errores.

Otra solución es ejecutar una rama "beta" de la aplicación separada de un subdominio y enrutar a los usuarios con la función beta. El problema con esto es que la complejidad de los certificados ssl, los enlaces de correo electrónico y otros problemas dependientes del dominio hacen que esto sea un poco molesto para el mantenimiento (aunque no tan malo como la primera solución).

¿Cómo puedo ofrecer esto de la manera más eficiente para minimizar el trabajo adicional para mantener y luego cambiar la versión beta a la versión completa?

Answer 1

Una posibilidad a considerar: decisiones (de un solo sentido, es decir, no reversibles) cambios destructivos a su modelo puede ser problemático por razones ajenas a la inhibición de su capacidad para proporcionar esta funcionalidad beta. Por ejemplo, puede ser difícil deshacer un cambio si tiene un problema durante la migración.

En su lugar, recomendaría buscar maneras de agregar solo al modelo: agregue columnas dejando viejas columnas en su lugar para compatibilidad con versiones anteriores, procedimientos almacenados de versiones si los está usando, etc.Si necesita modificar los tipos de datos de columna, en su lugar, cree una nueva columna del tipo de datos de destino, luego haga que su migración también copie los datos de filas existentes de la columna anterior a la columna nueva en el nuevo formato. A continuación, puede realizar la migración de la base de datos en su entorno de prueba y confirmar que tanto la versión anterior como la nueva de la aplicación continúen funcionando con los cambios en la base de datos.

Una posible forma de servir varias versiones de su aplicación es utilizar un formato alternativo de respuesta para su sitio beta. Podría crear un método en su ApplicationController para verificar si el usuario estaba en la versión beta. Si es verdadero, puede anular el valor de request.format y en su bloque responder_tiene una respuesta de tipo "format.beta".

El desafío con este enfoque es la lógica del controlador. Sin incrustar algún tipo de lógica de conmutación dentro de sus métodos de controlador, no tendrá una forma de alterar la ruta del código del controlador. Esto puede no ser un problema importante, dependiendo de cuántos cambios de controlador tenga.

(Por cierto, parece que tenemos nombres muy similares! :-))

Answer 2

Lo que puedo pensar es algo así como tener una columna user_type en su tabla de usuarios. para que pueda marcarlos como usuarios beta. (Incluso puede establecer esta marcar como predeterminado para que usted no necesita cambiar el código existente. Todas las nuevos usuarios que están creando serán los usuarios beta.)

Por esta Asumo

Usted está dando todas las características para sus usuarios beta Los usuarios beta tendrán la misma funcionalidad que tendrán los usuarios normales en el futuro.

** La única ventaja es que puede filtrar usuarios beta cuando inician sesión. Una vez que usted puede hacer algo como lo que permite iniciar sesión o no, etc ..

Cuando se cambia a la versión completa acaba de actualizar los usuarios beta como usuarios normales

No sé cómo esto es aplicable a su situación.

gracias

sameera

Answer 3

Yo personalmente no creo que sea una mala idea para envolver el código con un cheque por un usuario que tenga el papel beta . Será bastante fácil buscar todas las llamadas, por ejemplo if current_user.authorized?(:beta) y eliminarlas por completo.

Answer 4

Creo que la única posibilidad razonable de que este tipo de pruebas funcione sin afectar la aplicación actual sería utilizar un entorno de "preparación" y realmente solo redirigir a los usuarios beta a ese entorno.

Comparado con los problemas con las características relacionadas con el dominio, no es nada en comparación con las migraciones/problemas de funcionalidad.

En nuestra empresa hacemos exactamente eso, pero no tenemos lo de usuarios beta, pero sin un entorno separado, será bastante inviable para evitar que nuevas funciones entren en juego con las funciones actuales.

Por las características, sólo tiene que utilizar diferentes ramas de las nuevas características y crear ese ambiente "puesta en escena" de esa rama, una vez que las características se han probado sólo les fusionar a la cabeza y nueva característica está ahí:]

Answer 5

Una cosa en la que estoy pensando es crear un entorno beta "en etapas" que en realidad sea el entorno de producción. La idea sería tener beta.mydomain.com y luego enviar a los usuarios que quieran obtener las características anticipadamente. Básicamente, sería simplemente una rama que se implementa en el sitio beta que está en vivo.