テスト/ 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の両方がテストおよび承認されているが、マージされたときに競合が特定された場合、両方の機能の開発者は両方とも、テストを通過した機能ブランチであるため、自分自身の障害/ジョブではないと考えます。コミュニケーションには余分なオーバーヘッドがあり、競合を解決する人がいらいらすることもあります。

上記は私たちの物語です。リソースが限られているため、どこでもすべてをテストすることは避けたいと思います。私たちはこれに対処するためのより良い方法をまだ探しています。他のチームがこの種の状況をどのように処理するかを聞きたいです。

その方法は次のとおりです。

最新の開発ブランチコードをマージした後、機能ブランチでテストします。主な理由は、機能が受け入れられる前に開発ブランチコードを「汚染」したくないからです。テスト後に機能が受け入れられないが、開発時にすでにマージされている他の機能をリリースしたい場合、それは地獄です。開発は、リリースが行われるブランチであり、リリース可能な状態である必要があります。長いバージョンは、多くのフェーズでテストすることです。より分析的に：

1. 開発者は、新しい機能ごとに機能ブランチを作成します。
2. 機能ブランチは（自動的に）開発者がテストするすべてのコミットでTEST環境にデプロイされます。
3. 開発者が展開を完了し、機能をテストする準備ができたら、開発ブランチを機能ブランチにマージし、TESTで最新の開発変更をすべて含む機能ブランチを展開します。
4. テスターはTESTでテストします。完了したら、彼はストーリーを「受け入れ」、開発時に機能ブランチをマージします。開発者は以前に機能の開発ブランチをマージしていたので、通常はあまり多くの競合を予期しません。ただし、その場合は開発者が支援できます。これはトリッキーなステップです。これを回避する最善の方法は、機能をできるだけ小さく/特定的に保つことです。最終的には、さまざまな機能を何らかの方法でマージする必要があります。もちろん、チームの規模はこのステップの複雑さに影響を与えます。
5. 開発ブランチも（自動的に）TESTにデプロイされます。私たちは、ブランチのビルド機能が失敗する可能性があるとしても、ブランチの開発が失敗してはならないというポリシーを持っています。
6. 機能のフリーズに到達したら、開発からリリースを作成します。これは自動的にSTAGINGにデプロイされます。本番環境への展開前に、エンドツーエンドの広範なテストがそこで行われます。（OK多分私は少し誇張していますが、それほど広範囲ではありませんが、そうすべきだと思います）。理想的にはベータテスター/同僚、つまり実際のユーザーがそこでテストする必要があります。

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

テストの前に、開発ブランチから機能ブランチへの変更をマージします

いいえ。特に「私たち」がQAテスターの場合は、しないでください。マージには、潜在的な競合の解決が含まれます。これは、QAテスター（できるだけ早くテストを進める必要がある）ではなく、開発者（コードを知っている）が行うのが最善です。

開発者にの上でブランチのリベースをfeaturedevel実行させ、そのfeatureブランチをプッシュします（これは、開発者によって、最新のdevelブランチ状態の上でコンパイルおよび作業していることが検証されています）。
これにより、次のことが可能になります。

• 機能ブランチでの非常に単純な統合（ささいな早送りマージ）。
• または、以下のAspasia のコメントで推奨されているように、プルリクエスト（GitHub）またはマージリクエスト（GitLab）：メンテナーは、機能PR / MRブランチとの間でマージを行いますdevelopが、GitHub / GitLabによって競合が検出されない場合に限ります。

テスターはバグを検出するたびに、開発者に報告し、現在の機能ブランチを削除します。
開発者は次のことができます。

• バグを修正する
• 最近フェッチした開発ブランチの上にリベースします（ここでも、彼/彼女のコードが他の検証済み機能と統合して機能することを確認します）
• featureブランチをプッシュします。

一般的なアイデア：マージ/統合の部分は開発者が行い、テストはQAに任せます。

最善のアプローチは継続的インテグレーションであり、一般的なアイデアは機能ブランチを開発者ブランチにできるだけ頻繁にマージすることです。これにより、マージの手間が省けます。

可能な限り自動テストに依存し、Jenkinsによるユニットテストでビルドを自動的に開始します。開発者に変更をmainブランチにマージしてすべての作業を行わせ、すべてのコードの単体テストを提供します。

テスター/ QAは、コードレビューに参加し、ユニットテストをチェックし、自動統合テストを記述して、機能が完了したときに回帰スイートに追加できます。

詳細については、このリンクをチェックしてください。

「ゴールド」、「シルバー」、「ブロンズ」と呼ばれるものを使用します。これは、prod、stageing、およびqaと呼ばれます。

私はこれをるつぼモデルと呼んでいます。要件は技術と比較して理解するのが難しい場合があるため、ビジネス側でのQAの必要性が非常に高いため、これはうまく機能します。

バグまたは機能のテストの準備ができると、「ブロンズ」になります。これにより、事前に構築された環境にコードをプッシュするジェンキンスビルドがトリガーされます。私たちのテスター（ちなみに超技術者ではありません）はリンクをクリックするだけで、ソース管理を気にしません。このビルドはテストなども実行します。テスト（ユニット、統合、セレン）が失敗した場合、このビルドで実際にコードをテスト\ qa環境にプッシュしました。別のシステム（リードと呼ぶ）でテストする場合、変更がqa環境にプッシュされるのを防ぐことができます。

最初の恐れは、この機能間で多くの競合が発生することでした。機能Xによって機能Yが機能しなくなったように見える場合でも発生しますが、頻度は低く、実際に役立ちます。これは、変更のコンテキストであると思われるものの外側で、さまざまなテストを行うのに役立ちます。多くの場合、運によって、変更が並行開発にどのように影響するかがわかります。

機能がQAに合格したら、「シルバー」またはステージングに移行します。ビルドが実行され、テストが再度実行されます。毎週、私たちはこれらの変更を「ゴールド」または本番ツリーにプッシュし、それから本番システムに展開します。

開発者はゴールドツリーから変更を開始します。それらはすぐに上がるので、技術的にはステージングから始めることができます。

緊急修正は、ゴールドツリーに直接配置されます。変更が単純でQAが難しい場合は、直接シルバーに移行して、テストツリーに進むことができます。

リリース後、すべてを同期させるために、gold（prod）の変更をbronze（testing）にプッシュします。

ステージングフォルダーにプッシュする前にリベースすることができます。テストツリーをときどきパージすると、クリーンな状態が保たれることがわかりました。特に開発者が去った場合、テストツリーで機能が放棄されることがあります。

大規模なマルチ開発者向け機能の場合は、個別の共有リポジトリを作成しますが、準備が整ったらテストツリーにマージします。物事はQAから跳ね返る傾向があるため、ステージングツリーに追加してマージ/スカッシュできるように、チェンジセットを分離しておくことが重要です。

「ベーキング」もいい副作用です。基本的な変更がある場合は、しばらく座っておくとよいでしょう。

また、過去のリリースは維持されないことに注意してください。常に現在のバージョンが唯一のバージョンです。それでも、テスターやコミュニティがさまざまなコントリビューターがどのように相互作用するかを確認できるマスターベイクツリーを作成することもできます。

手動テストだけに頼るつもりはありません。Jenkinsを使用して、各機能ブランチのテストを自動化します。LinuxおよびWindowsですべてのブラウザーのJenkinsテストを実行するようにVMWareラボをセットアップしました。それは本当に素晴らしいクロスブラウザ、クロスプラットフォームテストソリューションです。Selenium Webdriverで機能/統合をテストします。私のセレンテストはRspecの下で実行されます。そして私はそれらをWindows上のjRubyによってロードされるように特別に書きました。私は、Rspecの下で従来の単体テストを実行し、Jasmineの下でJavascriptテストを実行します。Phantom JSでヘッドレステストをセットアップしました。

当社ではアジャイル開発を利用することができず、事業ごとの変更ごとに承認が必要なため、多くの問題を引き起こしています。

GITを使用するための私たちのアプローチはこれです。

弊社では「Git Flow」を実装しています。私たちはJIRAを使用しており、承認されたJIRAチケットのみが本稼働に移行する必要があります。テストの承認のために、別のテストブランチを作成しました。

JIRAチケットを処理する手順は次のとおりです。

1. Develop-Branchから新しいブランチを作成する
2. 機能ブランチでコード変更を行う
3. テスト/ QAブランチへの変更を機能から引き出す
4. 事業承認後、変更を機能ブランチから開発にプルします
5. 開発はリリースで頻繁に行われ、最後にマスターブランチ

各リクエストを独自の機能に分割することで、承認された変更のみが本番環境に送られます。

完全なプロセスは次のようになります。