QAとブランチを含むGitブランチモデル
Driessenのgitブランチモデル を使用したいのですが、QA側もあります。私はこのgitフローがどのように機能するか理解していると思いますが、テストについてはまだわかりません。たとえば、5つの新機能があり、それぞれが自分のブランチにあり、これらの機能をテストに提供したいとします。今、それらをどこにマージするかについて混乱していますか？ブランチを開発するには？もしそうなら、QAが2つだけを拒否し、5つすべての機能をすでにマージした場合はどうなりますか？自分のブランチで機能を分離し続けたいのですが、プルリクエストを使用してdiffとタイプコメントを表示したいのですが、どのブランチをマージするかという問題がありますか？
言い換えると、図によると、すべての新機能（つまり5）は開発ブランチにマージする必要があります。開発ブランチからリリースブランチへ、そしてリリースブランチからマスターへ（私は今のところホットフィックスについて気にしません-それらはかなり明確です）。しかし、QAとオプションのスペースはどこにありますか？次に、ダイアグラムで何を変更する必要がありますか？英語をお詫びします。できる限りのことをします。
どのGitブランチモデルを選択するかは、使用する開発プロセスに完全に依存します。あなたが言及した人気の「gitフロー」は、リリースが明確で、独自に開発された大規模な機能を持つ製品に関係しています。開発ブランチは、次のリリースの一部となる機能を表しています。
これにより、QAを実行できる2つの機会が開かれます。QAは、リリース指向または機能指向のいずれかで実行できます。
リリース指向のQAプロセスでは、リリースブランチが開始され、QAがその状態を確認します。 QAで問題が見つかった場合は、後で開発ブランチにマージされるリリースブランチで修正できます。これは、機能が完全に拒否されることになるような大きな問題がないことを前提としているため、かなり前にテストを行う必要があります。
リリース指向のQAプロセスは、半月ごとの定期的なリリース（たとえば、月に1つのリリース）で非常にうまく機能します。開発者は次のリリースの準備に1か月を費やします。その後、QAはリリースを1か月レビューします。この間、見つかった問題は修正されます。月末にバージョンがリリースされ、QAは開発者から次のバージョンを取得します。これにより、QAと開発者の両方のアイドル時間を回避できますが、機能の開始からリリースまでのサイクルタイムが長くなります。
機能指向のQAプロセスでは、機能は開発ブランチにマージされるときにレビューされます。したがって、開発ブランチの状態は常にQA済みで、リリースの準備ができています。これにより、長期間にわたってリスクが分散し、リリースに含まれる前に未対応の機能を拒否できます。関連のない機能を遅らせることもありません。
欠点は、一度に最大で1つの機能をQAできること、または異なる機能間の干渉を見逃す可能性があることです。これはプロセスのボトルネックになる可能性があり、小さくて簡単にレビューできる機能は推奨されません。
一部のQAアクティビティは、何かがマージされる前に実行することもできます。例えば。機能にユーザーインターフェイスの変更が含まれている場合は、リリースされる前に、その機能に対して個別に集中的なUXテストを実行できます。これは、開発者が赤テープをナビゲートすることなく、それが有用であると考えるときにQA支援を求めることができることを必要とします。これには、QAがこれらの要求に対応するのに十分な柔軟性があることも必要です。
これらの戦略はすべて組み合わせることができ、組み合わせる必要があります。リリースに近づくほどQAは重要になりますが、変更をより簡単に行うことができるため、以前のフィードバックはコスト効率が高くなります。
ここでは自動化とツールが大きなメリットをもたらすことに注意してください。これにより、プロセスが高速化および合理化され、生産性が飛躍的に向上します。これは、簡単なビルドとデプロイメントの自動化から始まり、QAは、確認したいブランチのソフトウェアを簡単に実行できます。テストの自動化により、QAを解放して、機能の検証、煙のテスト、手動の探索的テスト、新しいテストシナリオの開発など、より価値の高い高レベルのタスクを実行できます。これは実際にはどのプロセスや分岐スキームにも固有のものではありませんが、堅固なツールを使用することで、開発プロセスの早い段階でQAを容易に組み込むことができます。