私たちの開発チームはGitFlow分岐戦略を使用してきました。
最近、ソフトウェアの品質を向上させるために、2 人のテスターを採用しました。アイデアは、テスターによってすべての機能をテスト/QA する必要があるということです。
これまで、開発者は別々の機能ブランチで機能に取り組み、完了したらそれらをブランチにマージしていましたdevelop。feature開発者は、そのブランチで自分の作業を自分でテストします。今、テスターと共に、私たちはこの質問をし始めます
テスターはどのブランチで新機能をテストする必要がありますか?
明らかに、2 つのオプションがあります。
- 個々の機能ブランチで
develop枝に
開発ブランチでのテスト
当初は、次の理由から、これが確実な方法であると考えていました。
developこの機能は、開発が開始されて以来、ブランチにマージされた他のすべての機能でテストされています。- コンフリクトは早期に検出可能
developこれにより、テスターの仕事が簡単になります。テスターは常に 1 つのブランチ ( )を扱うだけです。どのブランチがどの機能に対応しているかを開発者に尋ねる必要はありません (機能ブランチは、関連する開発者によって独占的かつ自由に管理される個人的なブランチです)。
これに関する最大の問題は次のとおりです。
developブランチはバグで汚染されています。テスターがバグや競合を発見すると、開発者に報告し、開発者は開発ブランチの問題を修正します (フィーチャー ブランチはマージ後に放棄されました)。その後、さらに修正が必要になる可能性があります。複数のサブシーケンスのコミットまたはマージ (
developバグを修正するためにブランチがブランチから再度作成される場合) は、develop可能であればブランチから機能をロールバックすることを非常に困難にします。複数の機能がdevelopブランチにマージされ、さまざまな時点で修正されています。developこれは、ブランチの一部の機能だけを含むリリースを作成したい場合に大きな問題を引き起こします
機能ブランチでのテスト
そこで、もう一度考え直して、機能ブランチで機能をテストすることにしました。テストする前に、ブランチからフィーチャー ブランチに変更をマージしますdevelop(ブランチに追いつきますdevelop)。これはいい：
- メインストリームの他の機能で引き続き機能をテストします
developさらなる開発 (バグ修正、競合の解決など) によってブランチが汚染されることはありません。- 完全にテストされて承認されるまで、機能をリリースしないことを簡単に決定できます。
ただし、いくつかの欠点があります
- テスターはコードのマージを行う必要があり、競合が発生した場合 (非常に可能性が高い)、開発者に助けを求める必要があります。当社のテスターはテストを専門としており、コーディングはできません。
- 別の新しい機能が存在しなくても、機能をテストできます。たとえば、機能 A と B の両方が同時にテストされている場合、2 つの機能はどちらも
developブランチにマージされていないため、お互いを認識していません。developこれらは、両方の機能が開発ブランチにマージされたときに、ブランチに対して再度テストする必要があることを意味します。そして、将来これをテストすることを忘れないでください。 - 機能 A と B の両方がテストされて承認されたが、マージされたときに競合が特定された場合、両方の機能の両方の開発者は、機能ブランチがテストを通過したため、自分の責任/仕事ではないと信じています。通信には余分なオーバーヘッドがあり、競合を解決する人がイライラすることがあります。
以上が私たちの話です。リソースが限られているため、あらゆる場所ですべてをテストすることは避けたいと考えています。私たちはまだこれに対処するためのより良い方法を探しています. 他のチームがこの種の状況にどのように対処しているかを知りたいです。