[解決済み] テスト/QA プロセスと統合された Git ブランチ戦略

質問

私たちの開発チームは GitFlow ブランチング戦略を使っていますが、これは素晴らしいことです

最近、私たちはソフトウェアの品質を向上させるためにテスターを数人採用しました。このアイデアは、すべての機能がテスターによってテスト/QAされるべきであるというものです。

過去には、開発者は個別の機能ブランチで機能に取り組み、それらをマージして develop ブランチにマージしていました。開発者は自分の作業を、その feature ブランチでテストを行います。さて、テスターの場合、次のような質問を始めます。

テスターはどのブランチで新機能をテストすべきでしょうか？

明らかに、2つのオプションがあります。

• 個々の機能ブランチ上で
• ブランチ上で develop ブランチ

開発ブランチでのテスト

当初、私たちはこれが確実な方法だと信じていました。

• この機能は、他のすべての機能がマージされた状態でテストされ develop ブランチにマージされた他のすべての機能と一緒にテストされます。
• コンフリクトを早期に発見することができる
• テスターの仕事を簡単にします。彼は1つのブランチ ( develop ) を常に扱うだけです。どのブランチがどの機能のものかを開発者に尋ねる必要がありません (機能ブランチは、関連する開発者が独占的かつ自由に管理する個人的なブランチです)。

これの最大の問題点は

• は develop ブランチはバグで汚染されています。

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

フィーチャーブランチでのテスト

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

• メインストリームにある他の機能と一緒にその機能をテストしています。
• さらなる開発 (たとえばバグフィックスやコンフリクトの解決) は develop ブランチを汚染しません。
• その機能が完全にテストされ承認されるまでリリースしないことを簡単に決めることができます。

しかし、いくつかの欠点があります

• テスターはコードのマージを行わなければならず、もし衝突があれば (非常にありがちですが)、開発者に助けを求めなければならないのです。私たちのテスターはテストに特化しており、コーディングの能力はありません。
• ある機能が、別の新しい機能の存在なしにテストされる可能性がある。例えば、機能 A と B が同時にテストされている場合、2 つの機能はどちらもマージされていないため、お互いを知らないまま develop ブランチにマージされていないためです。これらのことから、テストする際には develop ブランチに対してテストをしなければならないことになります。そして、将来的にこれをテストすることを忘れないようにしなければなりません。
• 機能 A と B の両方がテストされ承認されたにもかかわらず、マージ時に競合が確認された場合、両方の機能の開発者の両方が、自分の機能ブランチがテストを通過したため、自分の責任/仕事ではないと考えてしまいます。コミュニケーションに余分なオーバーヘッドが発生し、コンフリクトを解決する人がフラストレーションを感じることがあります。

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

どのように解決するのですか？

やり方は以下の通りです。

私たちは、feature ブランチに最新の develop ブランチのコードをマージした後に、feature ブランチ上でテストを行います。主な理由は、機能が承認される前に開発ブランチのコードを汚染したくないからです。ある機能がテストの結果受け入れられなかったが、すでに develop ブランチにマージされている他の機能をリリースしたいという場合、それは地獄でしょう。開発ブランチはリリースが行われるブランチであり、リリース可能な状態であることが望ましいのです。長くなりましたが、私たちは多くのフェーズでテストを行っています。より分析的に。

1. 開発者はすべての新しい機能に対して機能ブランチを作成します。
2. feature ブランチは、開発者がテストできるように、コミットごとに (自動的に) テスト環境にデプロイされます。
3. 開発者がデプロイを終え、機能をテストする準備ができたら、develop ブランチを feature ブランチにマージし、最新の develop の変更をすべて含む feature ブランチをテスト環境にデプロイします。
4. テスターはテストブランチでテストを行います。それが終わると、彼はストーリーを受け入れ、feature ブランチを develop にマージします。開発者は以前に develop ブランチを feature にマージしていたので、通常はそれほど多くのコンフリクトは発生しないと思われます。しかし、もしそうであれば、開発者が手助けをすることができます。このステップは厄介で、これを避ける最善の方法は、機能を可能な限り小さく、具体的にしておくことだと私は思います。異なる機能は、最終的に何らかの方法でマージする必要があります。もちろん、チームの規模はこのステップの複雑さに影響を及ぼします。
5. develop ブランチは、(自動的に) TEST にもデプロイされます。features ブランチのビルドが失敗することがあっても、develop ブランチは決して失敗しないというポリシーがあります。
6. 機能のフリーズが完了したら、develop からリリースを作成します。これは自動的に STAGING にデプロイされます。本番環境へデプロイする前に、STAGING 上で大規模な End to End テストが行われます。(ちょっと大げさかもしれませんが、それほど大規模ではありませんが、そうあるべきだと思います）。理想的には、ベータテスターや同僚、つまり実際のユーザーがそこでテストすべきです。

このアプローチについてどう思われますか？