テスト/QAプロセスと統合されたGitブランチ戦略 質問する

私たちの開発チームは、GitFlow分岐戦略は素晴らしいです！

最近、ソフトウェアの品質向上のため、数名のテスターを採用しました。すべての機能はテスターに​​よってテスト/QA されるべきだという考え方です。

これまで、開発者は別々の機能ブランチで機能に取り組み、develop完了したらブランチにマージしていました。開発者は自分でそのfeatureブランチで作業をテストしていました。今ではテスターがいるので、次のような質問をします。

テスターはどのブランチで新しい機能をテストする必要がありますか?

明らかに、2 つの選択肢があります。

• 個々の機能ブランチ
• develop枝に

開発ブランチでのテスト

当初、私たちはこれが確実な方法であると信じていました。その理由は次のとおりです。

• developこの機能は、開発開始以降にブランチにマージされた他のすべての機能とともにテストされます。
• 競合は早期に検出可能
• これにより、テスターの仕事が楽になります。テスターはdevelop常に 1 つのブランチ ( ) だけを扱うことになります。どのブランチがどの機能用なのか開発者に尋ねる必要はありません (機能ブランチは、関連する開発者によって排他的かつ自由に管理される個人用ブランチです)。

これに関する最大の問題は次のとおりです。

• 枝developは虫で汚染されています。

  テスターがバグや競合を発見すると、開発者に報告し、開発者は開発ブランチで問題を修正します (機能ブランチはマージされると破棄されます)。その後、さらに修正が必要になる場合があります。複数のコミットまたはマージ (developバグを修正するためにブランチがブランチから再度作成される場合) により、developブランチから機能をロールバックすることが非常に困難になります (可能であれば)。複数の機能がさまざまなタイミングでブランチにマージされ、修正されます。これにより、ブランチdevelopの一部の機能のみを含むリリースを作成したい場合に大きな問題が発生します。develop

機能ブランチでのテスト

そこで、もう一度考えて、機能ブランチで機能をテストすることにしました。テストする前に、ブランチからdevelop機能ブランチに変更をマージします (ブランチに追いつくdevelop)。これは良いことです。

• 主流の他の機能と合わせて機能をテストする
• さらなる開発（バグ修正、競合の解決など）によってdevelopブランチが汚染されることはありません。
• 機能が完全にテストされ承認されるまでリリースしないことを簡単に決定できます。

しかし、欠点もいくつかある

• テスターはコードのマージを行う必要があり、競合が発生した場合は (非常に可能性が高い)、開発者に支援を求める必要があります。当社のテスターはテストを専門としており、コーディングを行うことはできません。
• 機能は、別の新機能がなくてもテストできます。たとえば、機能 A と機能 B の両方が同時にテストされている場合、どちらもブランチにマージされていないため、2 つの機能はお互いを認識しませんdevelop。つまり、両方の機能が開発ブランチにマージされたら、ブランチに対して再度テストする必要がありますdevelop。また、将来的にこれをテストすることを忘れないようにする必要があります。
• 機能 A と機能 B の両方がテストされ承認されたが、マージ時に競合が特定された場合、両方の機能の開発者は、自分の機能ブランチがテストを通過したため、自分の責任/仕事ではないと考えます。コミュニケーションに余分なオーバーヘッドが発生し、競合を解決している人がイライラすることがあります。

上記は私たちのストーリーです。リソースが限られているため、あらゆる場所ですべてをテストすることは避けたいと考えています。私たちはまだ、これに対処するためのより良い方法を模索しています。他のチームがこのような状況にどのように対処しているかをぜひ聞いてみたいです。