テスト/ QAプロセスと統合されたGit分岐戦略
私たちの開発チームは GitFlow ブランチング戦略を使用してきました。
最近、ソフトウェアの品質を向上させるために、テスターを数人募集しました。アイデアは、すべての機能をテスターがテスト/ QAする必要があるということです。
これまで、開発者は別々の機能ブランチで機能を操作し、完了したらそれらをdevelopブランチにマージします。開発者は、そのfeatureブランチで作業を自分でテストします。テスターと一緒に、この質問を始めます
テスターはどのブランチで新機能をテストする必要がありますか？
明らかに、2つのオプションがあります。
- 個々の機能ブランチ
developブランチ上
開発ブランチでのテスト
当初、私たちはこれが確実な方法だと信じていました。
- この機能は、開発が開始されて以来、
developブランチにマージされた他のすべての機能でテストされています。 - 競合は、より早く検出できます
- テスターの仕事を簡単にします。彼は常に1つのブランチ（
develop）だけを扱っています。どのブランチがどの機能に対応しているかについて開発者に尋ねる必要はありません（機能ブランチは、関連する開発者によって排他的かつ自由に管理される個人的なブランチです）
これの最大の問題は次のとおりです。
developブランチはバグで汚染されています。テスターはバグや競合を見つけると、開発者に報告します。開発者は開発ブランチの問題を修正し（機能ブランチはマージされると破棄されました）、その後さらに修正が必要になる場合があります。複数のサブシーケンスのコミットまたはマージ（バグを修正するために
developブランチからブランチを再作成する場合）は、可能であればdevelopブランチからの機能のロールバックを非常に困難にします。developブランチにマージされ、修正される複数の機能が異なる時間にあります。developブランチの機能の一部のみを含むリリースを作成する場合、これは大きな問題になります。
機能ブランチでのテスト
そこで私たちはもう一度考え、機能ブランチで機能をテストすることを決めました。テストする前に、変更をdevelopブランチから機能ブランチにマージします（developブランチに追いつきます）。これはいい：
- あなたはまだメインストリームの他の機能で機能をテストします
- 今後の開発（バグ修正、競合の解決など）は
developブランチを汚染しません。 - 完全にテストおよび承認されるまで、機能をリリースしないことを簡単に決定できます。
ただし、いくつかの欠点があります
- テスターはコードのマージを行う必要があり、競合がある場合（可能性が高い場合）、開発者に支援を求める必要があります。テスターはテストを専門としており、コーディングはできません。
- 機能は、別の新しい機能がなくてもテストできます。例えば機能Aと機能Bは両方とも同時にテスト中です。2つの機能は、どちらも
developブランチにマージされていないため、互いを認識していません。これらは、両方の機能がとにかく開発ブランチにマージされたときに、developブランチに対して再度テストする必要があることを意味します。そして、将来これをテストすることを忘れないでください。 - 機能AとBの両方がテストおよび承認されたが、マージ時に競合が識別された場合、両方の機能の開発者の両方は、機能ブランチがテストを過ぎたため自分の障害/ジョブではないと考えます。コミュニケーションには余分なオーバーヘッドがあり、競合を解決する人がいらいらすることもあります。
上記は私たちの物語です。リソースが限られているため、すべてをテストすることは避けたいと思います。これに対処するより良い方法を探しています。他のチームがこのような状況をどのように処理しているか聞いてみたいです。
その方法は次のとおりです。
最新の開発ブランチコードをマージした後、機能ブランチでテストします。主な理由は、機能が受け入れられる前に開発ブランチコードを「汚染」したくないからです。テスト後に機能が受け入れられない場合でも、開発中に既にマージされている他の機能は地獄になると思います。 Developはリリースが行われるブランチであるため、リリース可能な状態である必要があります。長いバージョンは、多くのフェーズでテストすることです。より分析的に：
- 開発者は、新しい機能ごとに機能ブランチを作成します。
- 機能ブランチは、開発者がテストするためにコミットするたびに、テスト環境に（自動的に）デプロイされます。
- 開発者が展開を完了し、機能をテストする準備が整ったら、開発ブランチを機能ブランチにマージし、TESTのすべての最新の開発変更を含む機能ブランチを展開します。
- テスターはTESTをテストします。作業が完了すると、彼はストーリーを「受け入れ」、開発時に機能ブランチをマージします。開発者は以前に機能の開発ブランチをマージしていたため、通常、あまり多くの競合は発生しません。ただし、その場合は、開発者が支援できます。これは難しいステップです。これを回避する最善の方法は、機能をできる限り小さく/特定することです。さまざまな機能を最終的にマージする必要があります。もちろん、チームの規模がこのステップの複雑さに影響します。
- 開発ブランチもTESTに（自動的に）デプロイされます。機能ブランチのビルドが失敗しても、開発ブランチは失敗しないというポリシーがあります。
- 機能の凍結に達したら、developからリリースを作成します。これは、STAGINGに自動的に展開されます。運用展開の前に、エンドツーエンドの広範なテストがそこで行われます。 （大丈夫かもしれませんが、大げさではありませんが、それほど大げさではありませんが、そうすべきだと思います）。理想的にはベータテスター/同僚、つまり実際のユーザーはそこでテストする必要があります。
このアプローチについてどう思いますか？
テストの前に、開発ブランチから機能ブランチに変更をマージします
いいえ。特に「私たち」がQAテスターである場合は、しないでください。マージには潜在的な競合の解決が含まれます。これは、QAテスター（できるだけ早くテストに進む必要がある）ではなく、開発者（コードを知っている）が行うのが最適です。
開発者にfeatureの上に自分のdevelブランチのリベースを行う、およびそのfeatureブランチをプッシュする（検証済み開発者がコンパイルして最新のdevelブランチ状態の上で作業している）。
それは以下を可能にします：
- 機能ブランチでの非常に簡単な統合（簡単な早送りマージ）。
- または、 Aspasia below コメント内 で推奨されているように、 pull request（GitHub） または merge request（GitLab） ：メンテナーは機能PR/MRブランチと
developの間のマージを行いますが、GitHub/GitLabによって競合が検出されない場合のみです。
テスターがバグを検出するたびに、開発者とdelete現在の機能ブランチにバグを報告します。
開発者は次のことができます。
- バグを修正する
- 最近フェッチされた開発ブランチの上にリベースします（再び、彼/彼女のコードが他の検証済み機能と統合して機能することを確認します）
featureブランチをプッシュします。
一般的なアイデア：マージ/統合部分が開発者によって行われていることを確認し、テストはQAに任せます。
「金」、「銀」、「青銅」と呼ばれるものを使用します。これは、prod、staging、およびqaと呼ばれます。
これをるつぼモデルと呼ぶようになりました。要件は技術よりも理解しにくいため、ビジネスの面でQAが非常に必要であるため、私たちにとってはうまくいきます。
バグまたは機能をテストする準備ができると、「ブロンズ」になります。これにより、コードを事前に構築された環境にプッシュするjenkinsビルドがトリガーされます。テスター（ちなみにスーパーテクではない）は、リンクをたたくだけで、ソース管理を気にしません。このビルドでは、テストなども実行されます。テスト（ユニット、統合、Selenium）が失敗した場合、実際にコードをtesting\qa環境にプッシュするこのビルドを行き来しました。別のシステムでテストする場合（リードと呼びます）、変更がqa環境にプッシュされるのを防ぐことができます。
最初の恐怖は、この機能の間に多くの矛盾があることでした。機能Xが機能Yが壊れているように見える場合に起こりますが、それは十分ではなく、実際に役立ちます。これは、変更のコンテキストと思われるものの外側で広範なテストを行うのに役立ちます。運がよければ、変更が並行開発にどのように影響するかがわかります。
機能がQAに合格すると、「シルバー」またはステージングに移行します。ビルドが実行され、テストが再度実行されます。毎週、これらの変更を「ゴールド」またはprodツリーにプッシュしてから、運用システムに展開します。
開発者はゴールドツリーから変更を開始します。技術的には、ステージングからすぐに開始できます。
緊急修正は、ゴールドツリーに直接組み込まれます。変更が簡単でQAに困難な場合、テストツリーへの道を見つけるシルバーに直接進むことができます。
リリース後、すべての同期を維持するために、gold（prod）の変更をbronze（testing）にプッシュします。
ステージングフォルダーにプッシュする前にリベースすることをお勧めします。テストツリーを時々パージすると、クリーンに保たれることがわかりました。特に開発者が去ると、テストツリーで機能が放棄されることがあります。
大規模なマルチ開発者向け機能の場合、個別の共有リポジトリを作成しますが、準備が整ったら同じようにテストツリーにマージします。 QAからバウンスする傾向があるため、変更セットを分離したままにして、ステージングツリーに追加してからマージ/スカッシュできるようにすることが重要です。
「ベーキング」もニースの副作用です。根本的な変化がある場合は、しばらくすてきな場所があります。
また、過去のリリースは維持していません。現在のバージョンが常に唯一のバージョンです。それでも、おそらくテスターやコミュニティがさまざまな貢献者のものがどのように相互作用するかを見ることができるマスターベーキングツリーを持つことができます。
手動テストだけに頼るつもりはありません。 Jenkinsを使用して、各機能ブランチのテストを自動化します。 LinuxおよびWindowsですべてのブラウザーのJenkinsテストを実行するようにVMWareラボをセットアップします。それは本当に素晴らしいクロスブラウザ、クロスプラットフォームのテストソリューションです。 Selenium Webdriverで機能/統合をテストします。私のSeleniumテストはRspecで実行されます。そして、Windows上のjRubyによってロードされるように特別に作成しました。 Rspecで従来の単体テストを実行し、JasmineでJavascriptテストを実行します。 Phantom JSでヘッドレステストをセットアップしました。