Estratégia para lidar com testes A / B e Gitflow

Gostaria de saber quais estratégias você usa para lidar com os testes A / B do seu aplicativo e do gitflow.

Visão geral:

Somos uma equipe de 6 programadores que desenvolvem e mantêm um aplicativo grande. Até agora, trabalhamos no gitflow com alguns complementos no processo adicionado por nós, que funcionaram perfeitamente por alguns anos. De uma maneira simplificada, usamos:

• ramificação mestre (apenas código das versões publicadas)
• ramo de liberação que mescla no mestre após testes finais de redundância
• hotfix que interage apenas com a ramificação mestre em casos extremos
• desenvolver que acumula os módulos desenvolvidos à medida que são finalizados e testados, eventualmente se fundindo na liberação.
• / feature, que é um grupo de recursos que se ramificam do desenvolvimento e, depois que terminam e passam os diferentes estágios do teste, se juntam novamente ao desenvolvimento, adicionando funcionalidades
• / fix_develop, que é um grupo de recursos que contêm correções para erros encontrados em versões anteriores que não são muito urgentes para iniciar um hotfix.

Agora, à medida que o aplicativo evolui, com a equipe de UX e outras equipes de partes interessadas, estamos adotando uma estratégia de teste A / B mais forte, em que os novos lançamentos terão 2 versões e com base em como nossos usuários, como uma versão ou outra, se tornarão o mestre final versão enquanto eles fizerem sentido para nossos usuários.

Tendo explicado isso, a pergunta é : Quais estratégias você usou ou recomenda para gerenciar o código das versões de teste A / B no gitflow?

As opções que considerei são inconsistentes, por exemplo, ramificando ramos A e B do mestre e juntando o ramo de lançamento a um ou outro, onde não sei como lidar com a separação do código contido do ramo de lançamento no recurso galhos. Outra opção é criar as ramificações das versões A e B e desenvolver ramificações A e B, o que soa como ramificações e confusão demais para meus companheiros de equipe.

Eu ouço suas opiniões, obrigado!

Atualização: o aplicativo que desenvolvemos é um aplicativo para Android e estamos implementando o teste A / B usando a plataforma PlayStore para testes A / B, que exige a criação de dois APKs e o upload de um deles com uma porcentagem de lançamento. Também para simplificar, e como as alterações às vezes podem ser maiores do que apenas a posição de um botão, decidimos não adicionar nossa própria opção para os testes A e B em um único APK.

A maneira que eu sempre vi isso é ter uma única base de código capaz de servir as duas páginas / visualizações / formulários.

ie Seu recurso sinalizado e implantado com duas ou mais configurações, ou o próprio método 'o usuário obtém A ou B' faz parte do aplicativo.

Nesse caso, você possui apenas uma versão do código, portanto seu controle de origem não entra em jogo.

Isso é muito mais preferível do que a alternativa de manter várias versões da base de código com recursos diferentes. Eles tendem a divergir muito rapidamente e você acaba implementando os mesmos recursos várias vezes.

Em geral, eu seria cuidadoso e restringiria o escopo das diferenças que A e B podem ter, para que possam ser conectadas a um método de comutação genérico (exibição A ou exibição B, por exemplo) e para que você possa entender os motivos de quaisquer estatísticas diferentes você sai do seu teste. por exemplo, o aumento nas vendas foi vinculado à cor do botão ou às fórmulas de preços?

Editar. para esclarecimentos sobre o aplicativo

Você ainda pode ter sinalizadores de recursos em um aplicativo da Play Store e empacotar a base de código em mais de um apk.

Concordo com @Ewan que as bandeiras de recursos são o caminho a percorrer. Dessa forma, você pode adicionar algo no processo de compilação que implantará o APK para o teste A ou B. Mas se quiser uma idéia que não use sinalizadores de recursos, aqui está uma que eu não tentei.

Você pode extrair o código comum em uma biblioteca separada em um repositório separado. Em seguida, cada versão do teste possui seu próprio repositório com seu próprio gitflow e ramificação mestre que podem ser implementados.

Isso exigirá mais esforço no começo, pois todo o código comum terá que ser extraído para a (s) biblioteca (s) e depois referenciado no repositório. Mas, após a configuração inicial, acredito que isso pode otimizar o desenvolvimento de novos recursos no teste A / B.

** Novamente, isso é apenas uma ideia e não algo que eu fiz pessoalmente.

Como seu aplicativo já está em execução e possui alguns usuários, sugiro uma das seguintes opções:

• Eu sugiro fortemente que você faça um design thinking antes de implementar um novo grande recurso;
• Se você ainda precisa fazer o teste A / B, sugiro que você mantenha o gitflow normal e tenha um ramo A e um ramo B ;

Fonte de controle

Considerando os testes A / B, o que eu quero deixar claro é que:

• Uma ramificação : contém código referente a uma versão do aplicativo. EG: A_HomeActivity, A_SettingsActivity, etc.
• Ramificação B : contém código referente à versão B do aplicativo. EG: B_HomeActivity, B_SettingsActivity etc.

A partir deste ponto, você pode usar 2 estratégias:

• Crie duas versões totalmente diferentes: A.apk e B.apk ; ou
• Faça com que a ramificação B também contenha código da ramificação A e forneça um aplicativo capaz de usar os dois fluxos . O usuário baixa apenas um aplicativo e tem a opção de ativar o novo fluxo para fins de avaliação. Eu já vi algo parecido com isto feito pelo Bitbucket , no qual uma navegação totalmente nova estava disponível para poucos usuários para avaliação; após algum período, essa nova navegação tornou-se a padrão.

De qualquer forma, após o experimento, você simplesmente remove o código do recurso / fluxo obsoleto.