Como ofereço um recurso beta para selecionar usuários? (Rails)

Question

Queremos começar a permitir que nossos usuários nos ajudem a testar nossas alterações no recurso antes de uma liberação mais ampla. Nosso aplicativo Rails já tem funções, mas não sei como devemos implementar um recurso beta sem mover todo o aplicativo.

Alguns problemas que não consigo pensar em soluções para:

• Um recurso beta pode exigir uma migração de banco de dados. Como você pode lidar com isso quando isso pode causar problemas com o aplicativo existente?
• Alterar modelos e o CSS/SASS provavelmente o alterarão para os recursos existentes também.
• Alterar o código do modelo subjacente pode quebrar os controladores / interfaces existentes que dependem dele.

Uma solução (uma opção ruim) é codificar no novo recurso e envolvê -lo na lógica que apenas o mostre se o usuário tiver a função "beta". O problema com isso é que, quando você finalmente o leva ao vivo, você pode ter muita desenrolamento/mudança para fazer. Isso é um desperdício de tempo e pode introduzir bugs.

Outra solução é executar uma ramificação "beta" separada do aplicativo de um subdomínio e rota os usuários com a função beta. O problema é que a complexidade dos certificados SSL, links de email e outros problemas dependentes de domínio tornam isso um pouco de dor de manutenção (embora não tão ruim quanto a primeira solução).

Como posso oferecer isso com mais eficiência para minimizar o trabalho adicional para manter e depois mudar a versão beta para a versão completa?

Answer 1

Uma possibilidade de considerar: tornar alterações destrutivas (ou seja, unidirecional, não reversíveis) em seu modelo pode ser problemático por razões além da inibição de sua capacidade de fornecer essa funcionalidade beta. Por exemplo, pode ser difícil recuar de uma mudança se você tiver um problema durante a migração.

Em vez disso, eu recomendaria procurar maneiras de adicionar apenas ao modelo: Adicionar colunas enquanto deixa colunas antigas para compatibilidade com versões anteriores, procedimentos armazenados de versão se você estiver usando -os, etc. Se precisar alterar os tipos de dados da coluna, crie, em vez disso, crie Uma nova coluna do tipo de dados de destino e, em seguida, faça com que sua migração também copie dados de linhas existentes da coluna antiga para a nova coluna no novo formato. Em seguida, você pode executar sua migração de banco de dados em seu ambiente de teste e confirmar que as versões antigas e novas do aplicativo continuam trabalhando com as alterações no banco de dados.

Uma maneira potencial de servir várias versões do seu aplicativo é usar um formato de resposta alternativo para o seu site beta. Você pode criar um método no seu ApplicationController para verificar se o usuário estava na versão beta. Se verdadeiro, você pode substituir o valor da solicitação.Format e, no seu bloco, responder uma resposta do tipo "formato.beta".

O desafio dessa abordagem é a lógica do controlador. Sem incorporar algum tipo de lógica de comutação nos métodos do controlador, você não terá uma maneira de alterar o caminho do código do controlador. Isso pode não ser um grande problema, dependendo de quantas alterações do controlador você tem.

(A propósito, parece que temos nomes muito semelhantes! :-))

Answer 2

Eu acho que a única chance razoável de esse tipo de teste funcionar sem afetar o aplicativo atual seria usar um ambiente de "encenação" e realmente redirecionar os usuários beta para esse ambiente.

Comparado aos problemas com os recursos relacionados ao domínio, não é realmente nada comparado aos problemas de migrações/funcionalidade.

Em nossa empresa, fazemos exatamente isso, mas não temos a coisa dos usuários beta, mas sem um ambiente separado, será praticamente invejável impedir que novos recursos mexem com os recursos atuais.

Para os recursos, basta usar ramificações diferentes para esses novos recursos e criar esse ambiente de "encenação" a partir dessa filial, uma vez que os recursos forem testados, você apenas os mescla para a cabeça e o novo recurso está lá:

Answer 3

O que consigo pensar é algo como ter uma coluna User_Type na tabela de usuários. para que você possa sinalizar -os como usuários beta. (Mesmo você pode definir esse sinalizador como padrão para que você não precise alterar o código existente. Todos os novos usuários que estão criando serão usuários beta.)

Para isso estou assumindo

Você está dando todos os recursos aos usuários beta dos usuários beta terão a mesma funcionalidade que terá pelo usuário normal no futuro.

** A única vantagem é que você pode filtrar os usuários beta como e quando eles estão login. Sobre isso você pode fazer algo como permitir fazer login ou não etc.

Quando você está mudando para a versão completa, apenas atualize os usuários beta como usuários normais

Não sei como isso é aplicável ao seu cenário.

obrigado

Sameera

Answer 4

Pessoalmente, não acho que seja uma má idéia envolver o código com um cheque para um usuário ter a função beta. Será muito fácil procurar todas as chamadas para, por exemplo if current_user.authorized?(:beta) e removê -los completamente.

Answer 5

Uma coisa que estou pensando em fazer é configurar um ambiente de "encenação" beta que é realmente o ambiente de produção. A idéia seria ter beta.mydomain.com e depois enviar usuários para lá que desejam obter os recursos mais cedo. Basicamente, seria apenas um ramo que é implantado no site beta, que está ao vivo.