Estrategia para lidiar con pruebas A / B y Gitflow

Me gustaría saber qué estrategias utiliza para lidiar con las pruebas A / B de su aplicación y gitflow.

Visión general:

Somos un equipo de 6 programadores que desarrollamos y mantenemos una gran aplicación. Hasta ahora hemos trabajado en gitflow con algunos complementos en el proceso agregado por nosotros que funcionó perfectamente bien durante un par de años. De manera simplificada, utilizamos:

• rama maestra (solo código de versiones publicadas)
• versión de lanzamiento que se fusiona en el maestro después de las pruebas finales de redundancia
• revisión que solo interactúa con la rama maestra en casos extremos
• desarrollar, que acumula los módulos desarrollados a medida que se terminan y prueban, y finalmente se fusionan con el lanzamiento.
• / feature, que es un grupo de características que se ramifican desde el desarrollo y una vez que finalizan y pasan las diferentes etapas de prueba, se fusionan nuevamente con el desarrollo, agregando funcionalidad
• / fix_develop, que es un grupo de características que contienen correcciones a errores encontrados en versiones anteriores que no son demasiado urgentes para iniciar una revisión.

Ahora, a medida que la aplicación evoluciona, con el equipo de UX y otros equipos de partes interesadas, estamos adoptando una estrategia de prueba A / B más sólida donde los nuevos lanzamientos tendrán 2 versiones, y en función de cómo nuestros usuarios como una versión u otra se convertirán en el maestro final versión mientras tengan sentido para nuestros usuarios.

Habiendo explicado eso, la pregunta es : ¿Qué estrategias ha utilizado o recomendado para administrar el código de las versiones de prueba A / B en gitflow?

Las opciones que he considerado son de alguna manera inconsistentes, por ejemplo, bifurcar ramas A y B del maestro y luego unir la rama de lanzamiento a una u otra, donde no sé cómo tratar la separación del código contenido de la rama de lanzamiento para presentar ramas Otra opción es crear ramas de lanzamiento A y B y desarrollar ramas A y B que suenan como demasiadas ramas y confusión para mis compañeros de equipo.

Escucho tus opiniones, gracias!

Actualización: La aplicación que desarrollamos es una aplicación de Android y estamos implementando las pruebas A / B utilizando la plataforma PlayStore para las pruebas A / B, que requiere crear dos APK y cargar uno de ellos con un% de despliegue. Además, para simplificar las cosas, y dado que los cambios a veces pueden ser mayores que la simple posición de un botón, decidimos no agregar nuestro propio interruptor para las pruebas A y B en un solo APK.

La forma en que siempre lo he visto es tener una única base de código capaz de servir tanto páginas / vistas / formularios.

es decir. Su característica marcada y desplegada con dos o más configuraciones, o el método 'el usuario obtiene A o B' en sí mismo es parte de la aplicación.

En este caso, solo tiene una versión del código, por lo que su control de origen no entra en juego.

Esto es mucho más preferible que la alternativa de mantener múltiples versiones de la base de código con diferentes características. Estos tienden a divergir muy rápidamente y terminas teniendo que implementar las mismas funciones varias veces.

En general, sería cuidadoso y restringiría el alcance de las diferencias que A y B pueden tener para que puedan conectarse a un método de cambio genérico (vista A o vista B, por ejemplo) y para que pueda comprender las razones de cualquier estadística diferente sales de tus pruebas. por ejemplo, ¿el aumento de las ventas estuvo relacionado con el color del botón o las fórmulas de fijación de precios?

Editar. para aclarar la aplicación

Todavía puede tener indicadores de características en una aplicación de Play Store y empaquetar la base de código en más de un apk.

Estoy de acuerdo con @Ewan en que las banderas de funciones son el camino a seguir. De esa manera, puede agregar algo en el proceso de compilación que implementará APK para la prueba A o la prueba B. Pero si desea una idea que no use indicadores de características, aquí hay una que no he probado.

Podría extraer el código común en una biblioteca separada en un repositorio separado. Luego, cada versión de la prueba tiene su propio repositorio con su propio gitflow y rama maestra que se puede implementar.

Esto requerirá más esfuerzo al principio, ya que todo el código común tendrá que extraerse a la (s) biblioteca (s) y luego referenciarse en el repositorio. Pero después de la configuración inicial, creo que esto puede optimizar el desarrollo de nuevas características en la prueba A / B.

** Nuevamente, esto es solo una idea y no es algo que haya hecho personalmente.

Como su aplicación ya se está ejecutando y tiene algunos usuarios, le sugiero una de las siguientes opciones:

• Le sugiero encarecidamente que haga un pensamiento de diseño antes de implementar una nueva gran característica;
• Si aún necesita hacer la prueba A / B, le sugiero que mantenga el flujo normal y tenga una rama A y una rama B ;

Fuente de control

Considerando las pruebas A / B, lo que quiero dejar en claro es que:

• Una rama : contiene código con respecto a una versión de la aplicación. Por ejemplo: A_HomeActivity, A_SettingsActivity, etc.
• Rama B : contiene código con respecto a la versión B de la aplicación. Por ejemplo: B_HomeActivity, B_SettingsActivity, etc.

A partir de este punto, podría usar 2 estrategias:

• Cree dos versiones totalmente diferentes: A.apk y B.apk ; o
• Haga que la rama B también contenga código de la rama A y proporcione una aplicación capaz de usar los dos flujos . El usuario descarga solo una aplicación y tiene la opción de activar el nuevo flujo para fines de evaluación. He visto algo como esto hecho por Bitbucket , en el cual una navegación totalmente nueva estaba disponible para pocos usuarios para evaluación; Después de un período, esta nueva navegación se convirtió en la predeterminada.

De cualquier manera, después del experimento, simplemente elimina el código de la característica / flujo obsoleto.