Estrategia para lidiar con pruebas A / B y Gitflow

8

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.

alexm
fuente
¿No son simplemente ramas de características?
Robert Harvey
1
Lo que pasa es que estas ramas irán a la tienda, por lo que tendrían que romper todos los protocolos de prueba si solo subo el código de las ramas de características. ¿Qué piensas?
alexm
¿Vas a pasar por todo el proceso de investigación de antecedentes para una sucursal que nunca se convertirá en un producto real? ¿No es eso esencialmente el doble de tu trabajo?
Robert Harvey
de todos modos, así es como lo veo ahora, mi idea con la publicación es aprender cómo otras personas lidian con este asunto y aplicar lo que creo que tendría sentido para nosotros
alexm
duplica el trabajo, pero hay cosas esenciales que debemos probar y probar si funcionan para nuestros usuarios que son bastante complejas, todo esto se hace para agrandar la parte inferior del panel de nuestro usuario activo, por lo que es mucho trabajo, pero tiene sentido probar
alexm

Respuestas:

11

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.

Ewan
fuente
3
Sí, esto es lo que iba a sugerir: marcado de funciones. El único problema con él es que aumenta la complejidad de su software, a menos que tenga la intención de eliminar las características (no utilizadas) en la versión siguiente.
Robert Harvey
1
Sí, por lo general no estoy a favor de los indicadores de funciones, pero esta es la forma en que lo hice y lo vi. Estoy seguro de que todos hemos visto los horrores que puedes tener al tener múltiples versiones en vivo del mismo producto en sucursales. Así que, naturalmente, me alejaría de ese enfoque.
Ewan
2
aún puede tener configuraciones de configuración y obtener dos aplicaciones de la misma base de código. Claro que su aplicación será más grande, pero ... mantener múltiples bases de código es un desafío, por decir lo menos
Ewan
2
seguramente ese tipo de flujo se puede resumir en una vista
Ewan
1
Sí, para un equipo de desarrollo empresarial, sugeriría que sí. Para mí, en un entorno de desarrollo empresarial intensamente comprometido, el flujo de desarrollo base troncal es mucho más fácil. Echa un vistazo aquí: trunkbaseddevelopment.com . Sam Newman tuvo una buena charla sobre alternar funciones en youtube: youtube.com/watch?v=lqRQYEHAtpk .
ivenxu
1

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.

DFord
fuente
Sí, eso tiene sentido, tenemos una biblioteca con la funcionalidad principal (C ++) y luego aplicaciones de consumo (Android e iOS) que solo sirven como implementadores de interfaz y servicio, lo que estamos cambiando es la forma en que la aplicación se presenta al usuario, así que sí, eso funcionaría para las pruebas A / B en Android. Sin embargo, estoy buscando tener el código centralizado en un repositorio, así que estoy buscando una estrategia de gitflow en medio de: "copiar todas las ramas para A y B" y "tener solo una característica A y B o una rama normal lo que significaría un repositorio sucio ".
alexm
0

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.

Emerson Cardoso
fuente