I would like to know what strategies do you use to deal with A/B tests of your app and gitflow.
Overview:
We are a team of 6 programmers who develop and maintain a large App. So far we have worked on gitflow with a few add-ons on the process added by us which worked perfectly well for a couple years. In a simplified way, we use:
- master branch (only code of published versions)
- release branch which merges in master after final redundancy tests
- hotfix which only interacts with master branch in extreme cases
- develop which accumulates the developed modules as they are finished and tested, eventually merging into release.
- /feature which is a group of features that branch from develop and once they are finished and pass the different stages of testing merge back into develop adding functionality
- /fix_develop which is a group of features that contain fixes to bugs encountered from earlier versions that are not too urgent to start a hotfix.
Now, as the app evolves, with the UX team and other stakeholder teams we are adopting a stronger A/B testing strategy where new releases will have 2 versions, and based on how our users like one version or the other will become the final master version for as long as they make sense for our users.
Having explained that, the question is: What strategies have you used or recommend to manage code of A/B testing versions in gitflow?
The options I've considered are somehow inconsistent, for example branching A and B branches from master and then joining the release branch to one or the other, where I don't know how to deal with separating the code contained from release branch to feature branches. Another option is creating release A,and B branches and develop A and B branches which sounds like too much branches and confusion for my team mates.
I hear your opinions, thanks!
Update: The App we develop is an Android App and we are implementing the A/B testing using PlayStore platform for A/B testing, which requires to create two APKs and upload one of them with a rollout %. Also to keep things simpler, and since changes may sometimes be greater than just a button position, we decided not to add our own switch for A and B testing in one single APK.