6
テスト/ QAプロセスと統合されたGit分岐戦略
私たちの開発チームはGitFlow分岐戦略を使用してきました。 最近、ソフトウェアの品質を向上させるために、テスターを数名採用しました。アイデアは、すべての機能がテスターによってテスト/ QAされるべきであるということです。 以前は、開発者は別々の機能ブランチで機能に取り組みdevelop、完了したらそれらをブランチにマージします。開発者は自分の作業をそのfeatureブランチで自分でテストします。今、テスターと一緒に、私たちはこの質問をし始めます テスターはどのブランチで新機能をテストする必要がありますか？ 明らかに、2つのオプションがあります。 個々の機能ブランチ 上のdevelop枝 開発ブランチでのテスト 最初は、これが確実な方法であると信じていました。 この機能は、develop開発が始まってからブランチにマージされた他のすべての機能でテストされます。 競合は早期に検出できます これにより、テスターの作業が簡単になり、develop常に1つのブランチ（）のみを処理します。彼は開発者に、どのブランチがどの機能に対応するかを尋ねる必要はありません（機能ブランチは、関連する開発者が独占的に自由に管理する個人のブランチです） これに関する最大の問題は次のとおりです。 developブランチはバグで汚染されています。 テスターはバグまたは競合を発見すると、開発者に報告し、開発ブランチで問題を修正します（機能ブランチはマージされると中止されました）。その後、さらに修正が必要になる場合があります。複数のサブシーケンスのコミットまたはマージ（developバグを修正するためにブランチからブランチが再作成される場合）はdevelop、可能であればブランチからの機能のロールバックを非常に困難にします。developブランチにマージされ、ブランチで修正される複数の機能があります。これは、developブランチの一部の機能のみを含むリリースを作成するときに大きな問題を引き起こします 機能ブランチでのテスト そこで、もう一度考えて、機能ブランチで機能をテストする必要があると判断しました。テストする前に、developブランチからの変更を機能ブランチにマージします（ブランチに追いつきますdevelop）。これはいい： あなたはまだ主流の他の機能で機能をテストします さらなる開発（バグの修正、競合の解決など）によってdevelopブランチが汚染されることはありません。 完全にテストおよび承認されるまで、機能をリリースしないことを簡単に決定できます。 ただし、いくつかの欠点があります テスターはコードのマージを行う必要があり、競合がある場合（非常に可能性が高い）、開発者に支援を依頼する必要があります。当社のテスターはテストを専門としており、コーディングはできません。 機能は、別の新しい機能がなくてもテストできます。たとえば、機能AとBは両方とも同時にテスト中ですが、どちらもdevelopブランチにマージされていないため、2つの機能は互いに認識していません。つまりdevelop、両方の機能が開発ブランチにマージされたときに、ブランチに対して再度テストする必要があります。そして、これを将来テストすることを忘れないでください。 機能AとBの両方がテストおよび承認されているが、マージされたときに競合が特定された場合、両方の機能の開発者は両方とも、テストを通過した機能ブランチであるため、自分自身の障害/ジョブではないと考えます。コミュニケーションには余分なオーバーヘッドがあり、競合を解決する人がいらいらすることもあります。 上記は私たちの物語です。リソースが限られているため、どこでもすべてをテストすることは避けたいと思います。私たちはこれに対処するためのより良い方法をまだ探しています。他のチームがこの種の状況をどのように処理するかを聞きたいです。