A / BテストとGitflowを処理するための戦略

アプリとgitflowのA / Bテストを処理するためにどのような戦略を使用していますか。

概要：

私たちは、大きなアプリを開発して維持する6人のプログラマーのチームです。これまでのところ、私たちはgitflowに取り組んでおり、数年前から完全にうまく機能していたプロセスにいくつかのアドオンを追加しました。簡単に言うと、次のように使用します。

• マスターブランチ（公開バージョンのコードのみ）
• 最終的な冗長性テストの後にマスターにマージするリリースブランチ
• 極端な場合にのみmasterブランチと対話する修正プログラム
• 開発とモジュールの完成とテストが完了した時点で蓄積され、最終的にリリースにマージされます。
• / featureは、開発から分岐し、それらが完了してテストのさまざまな段階を通過すると、機能を追加する開発にマージして戻る機能のグループです。
• / fix_developは、以前のバージョンで発生したバグの修正を含む機能のグループであり、ホットフィックスを開始するのに緊急ではないものです。

アプリが進化するにつれ、UXチームや他の利害関係者チームとともに、新しいリリースに2つのバージョンがあり、ユーザーがいずれかのバージョンを好むかどうかに基づいて、より強力なA / Bテスト戦略を採用しています。ユーザーにとって意味のあるバージョンである必要があります。

それを説明したら、問題は次のとおりです。gitflow でA / Bテストバージョンのコードを管理するために、どのような戦略を使用または推奨しましたか？

私が検討したオプションは、どういうわけか一貫性がありません。たとえば、AブランチとBブランチをマスターからブランチしてから、リリースブランチをどちらかに結合します。リリースブランチに含まれるコードを機能に分離する方法を知りません。枝。別のオプションは、リリースAとBのブランチを作成し、AとBのブランチを開発することです。これは、ブランチが多すぎてチームメイトにとって混乱のように思えます。

あなたの意見を聞いて、ありがとう！

更新： 開発するアプリはAndroidアプリであり、A / Bテスト用にPlayStoreプラットフォームを使用してA / Bテストを実装しています。これには、2つのAPKを作成し、そのうちの1つをロールアウト％でアップロードする必要があります。また、物事をよりシンプルに保つため、またボタンの位置よりも変更が大きい場合があるため、1つのAPKにAおよびBテスト用の独自のスイッチを追加しないことにしました。

私がいつもそれを行っていると思った方法は、両方のページ/ビュー/フォームを処理できる単一のコードベースを持つことです。

すなわち。その機能にフラグが立てられ、2つ以上の構成で展開されているか、「ユーザーがAまたはBを取得するか」メソッド自体がアプリの一部です。

この場合、コードのバージョンは1つだけなので、ソース管理は機能しません。

これは、異なる機能を持つコードベースの複数のバージョンを保持する代わりの方法よりもはるかに好ましいです。これらはすぐに分岐する傾向があり、同じ機能を複数回実装する必要があります。

一般に、私は注意して、AとBの両方が持つ可能性のある違いの範囲を制限します。これにより、AとBを汎用のスイッチメソッド（ビューAまたはビューBなど）にプラグインでき、異なる統計の理由を理解できるようになります。テストから抜け出します。たとえば、売上の増加はボタンの色や価格式に関連していたのでしょうか？

編集。アプリの説明のため

Playストアアプリに機能フラグを設定して、コードベースを複数のAPKにパッケージ化することもできます。

フィーチャーフラグを使用する方法であることに@Ewanに同意します。そうすることで、AテストまたはBテストのいずれかでAPKをデプロイするビルドプロセスに何かを追加できます。ただし、機能フラグを使用しないアイデアが必要な場合は、ここで私が試したことがありません。

共通のコードを別のリポジトリーの別のライブラリーに引き出すことができます。次に、テストの各バージョンには、デプロイ可能な独自のgitflowとマスターブランチを持つ独自のリポジトリがあります。

すべての共通コードをライブラリーにプルしてからリポジトリーで参照する必要があるため、これは最初により多くの労力を要します。しかし、初期設定後は、これによりA / Bテストへの新機能の開発を合理化できると思います。

**繰り返しますが、これは単なるアイデアであり、私が個人的に行ったものではありません。

アプリは既に実行されており、一部のユーザーがいるため、次のオプションのいずれかをお勧めします。

• 新しい大きな機能を実装する前に、デザイン思考を行うことを強くお勧めします。
• それでもA / Bテストを行う必要がある場合は、通常のgitflowを使用して、AブランチとBブランチを作成することをお勧めします。

ソース管理

A / Bテストを考えると、私が明確にしたいのは、

• ブランチ：アプリのバージョンに関するコードが含まれています。EG：A_HomeActivity、A_SettingsActivityなど
• Bブランチ：アプリのBバージョンに関するコードが含まれています。EG：B_HomeActivity、B_SettingsActivityなど

この時点から、2つの戦略を使用できます。

• 2つのまったく異なるバージョンを作成します。A.apkとB.apkです。または
• BブランチにAブランチのコードも含めるようにして、2つのフローを使用できるアプリを提供します。ユーザーは1つのアプリのみをダウンロードし、評価目的で新しいフローをオンにするオプションがあります。このようなBitbucketによるものを見たことがありますが、評価のためにまったく新しいナビゲーションを利用できるユーザーはほとんどいませんでした。しばらくすると、この新しいナビゲーションがデフォルトになりました。

どちらの方法でも、実験後は、廃止された機能/フローのコードを削除するだけです。