Stratégie pour traiter des tests A / B et de gitflow
J'aimerais savoir quelles stratégies utilisez-vous pour traiter des tests A/B de votre application et de votre gitflow?
Vue d'ensemble :
Nous sommes une équipe de 6 programmeurs qui développent et gèrent une grande application. Jusqu'à présent, nous avons travaillé sur Gitflow avec quelques add-ons au processus ajouté par nous qui fonctionnaient parfaitement pendant quelques années. De manière simplifiée, nous utilisons:
- maître Direction (seul code de versions publiées)
- libération branche qui fusionne en maître après des tests de redondance finaux
- hotfix qui n'interagit que avec la branche principale dans des cas extrêmes
- Développement qui accumule les modules développés tels qu'ils sont terminés et testés, finissent par la fusionner dans la libération.
- / fonctionnalité qui est un groupe de fonctionnalités que la branche de développement et une fois qu'ils sont finies et transmettent les différentes étapes des tests fusionnées dans le développement de l'ajout de fonctionnalités
- / fix_develop qui est un groupe de fonctionnalités contenant des corrections aux bogues rencontrées à partir de versions antérieures qui ne sont pas trop urgentes pour démarrer un correctif.
À mesure que l'application évolue, avec l'équipe UX et d'autres équipes de parties prenantes, nous adoptons une stratégie de test A/B renforcée où de nouvelles versions auront 2 versions et sur la base de la manière dont nos utilisateurs comme une version ou l'autre deviendront le dernier maître version pour tant qu'ils ont un sens pour nos utilisateurs.
Après avoir expliqué que, la question est: Quelles stratégies avez-vous utilisées ou recommandées à gérer le code des versions de test A/B IN Gitflow?
Les options que j'ai envisagées sont en quelque sorte incohérentes, par exemple branlant des branches A et B de Master, puis rejoignent la branche de déverrouillage à l'une ou l'autre, où je ne sais pas comment faire face à la séparation du code contenu de la branche de libération à la fonctionnalité. branches. Une autre option consiste à créer une version A, et des branches B et développez des branches A et B qui ressemblent à trop de branches et de confusion pour mes camarades d'équipe.
J'entends tes opinions, merci!
Mise à jour : L'application que nous développons est une application Android application et nous implémentons les tests A/B à l'aide de plate-forme PlayStore pour les tests A/B, qui nécessite de créer deux APKS. et télécharger l'un d'entre eux avec un% de déploiement. Également pour garder les choses plus simples, et puisque les changements peuvent parfois être supérieurs à une position de bouton, nous avons décidé de ne pas ajouter notre propre commutateur pour un test A et B dans un seul APK.
La façon dont j'ai toujours vue, c'est avoir une seule base de code unique capable de servir les pages/vues/formulaires.
c'est à dire. Sa caractéristique marquée et déployée avec deux configures ou plus, ou la méthode 'L'utilisateur obtienne-t-elle une méthode ou B' est-elle elle-même fait partie de l'application.
Dans ce cas, vous n'avez qu'une version unique du code, votre contrôle de source n'entre pas en jeu.
Ceci est beaucoup plus préférable que l'alternative de maintenir plusieurs versions de la base de code avec différentes fonctionnalités. Celles-ci ont tendance à diverger très rapidement et vous finissez par avoir à mettre en œuvre les mêmes caractéristiques plusieurs fois.
En général, je ferais attention et restreindre la portée des différences A et B peut avoir les deux afin de pouvoir être branchés dans une méthode de commutation générique (vue a ou vue B par exemple) et afin de pouvoir comprendre les raisons de toutes les statistiques différentes. Vous sortez de vos tests. Par exemple, l'augmentation des ventes liées à la couleur du bouton ou aux formules de tarification?
Éditer. Pour clarification de l'application
Vous pouvez toujours avoir des indicateurs de fonctionnalités dans une application Play Store et emballer le codeBase dans plusieurs APK.