web-dev-qa-db-ja.com

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

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

概要：

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

  • masterブランチ（公開されたバージョンのコードのみ）
  • release最終冗長テスト後にマスターにマージするブランチ
  • hotfix極端な場合にのみmasterブランチと相互作用します
  • develop開発およびテストが終了すると、開発されたモジュールが蓄積され、最終的にリリースにマージされます。
  • / featureこれは、開発から分岐し、終了すると、テストのさまざまな段階を通過して機能を追加する開発にマージする機能のグループです。
  • / fix_developこれは、以前のバージョンで発生した、ホットフィックスを開始するのに緊急ではないバグの修正を含む機能のグループです。

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

それを説明した後、質問は：A/Bテストバージョンのコードを管理するためにどのような戦略を使用または推奨しましたかin gitflow？

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

ご意見ありがとうございます！

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

acceptance-testinggitflowdevelopment
8
alexm

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

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

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

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

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

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

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

11
Ewan

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

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

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

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

1
DFord

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

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

ソース管理

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

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

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

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

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

0
Emerson Cardoso