web-dev-qa-db-ja.com

Git Flowは、リリースと新機能の両方をテストするQAとどのように連携しますか？

私たちは最新のiOSプロジェクトでGit Flowを使用しており、QAで作業する方法を模索しています。QAを使用して、修正されたバグを心配することなく、新機能をテストできるだけでなく、最新のリリースをテストできます。どの枝。

現在、彼らはrelease/v1.0.1ブランチでテストしており、元のrelease/v1.0からいくつかのバグが修正されています。同時に、v1.1リリースで計画されている新機能に取り組んでいますが、release/v1.0.1と同時にdevelopブランチから分岐しているため、バグ修正はありません。

本日、QA部門が私の新機能を試乗したいと考えています。ただし、自分のブランチからビルドを作成した場合、再テストしてクローズしたバグ修正はそこには含まれません。そのため、再導入されたバグについての苦情やパニックが殺到します...避けたい！

それで、彼らにこれをテストさせる最良の方法は何ですか？ release/v1.0.1を機能ブランチにマージすることはできますが、release/v1.0.1がリリースされる前にdevelopにマージしないように注意する必要があります。方法論。 QAテスト専用の完全に新しいブランチを作成し、私の機能をrelease/v1.0.1とマージすることができますが、このブランチで見つかったバグをどうすればよいですか？ QAのラウンド後、どこにマージし直すのですか？

これらすべてに加えて、ビルド番号とバージョン番号を考慮して、意味がわかるようにする必要があります。現在、リリースに使用されているのはバージョン番号であり、ビルド番号はQAの新しいビルドごとに増加します。ただし、2つの別々のブランチからビルドを受け取っている場合、ビルド番号の衝突が発生して混乱を招く可能性があります。

これらの問題に対処する最良の方法は何でしょうか？

gittestingbranching-and-mergingqagit-flow
21
jowie

最初の図の一部については、回答全体を通して nvie.comのGitフローページ から参照します。完成させるために、以下にスクリーンショットを追加しました。

enter image description here

本日、QA部門が私の新機能を試乗したいと考えています。ただし、自分のブランチからビルドを作成した場合、再テストしてクローズしたバグ修正はそこには含まれません。そのため、再導入されたバグについての苦情やパニックが殺到します...避けたい！

それで、彼らにこれをテストさせる最良の方法は何ですか？ release/v1.0.1を機能ブランチにマージすることもできますが、リリース/v1.0.1がリリースされる前に開発にマージしないことを確認する必要があります `...

番号;リリースブランチを機能ブランチに直接マージしないでください。 Git Flowモデルによると、（継続的に）

  1. release/v.1.0.1をdevelopブランチにマージし、
  2. developを機能ブランチにマージし、

release/v.1.0.1からの安定した変更を機能ブランチに取り込むため。

enter image description here

（残念ながら、上の画像はdevelopからfeatureへの継続的なマージを示していませんが、それはあなたがすべきことです。）

QAテスト専用の完全に新しいブランチを作成できます。これは、私の機能をrelease/v1.0.1とマージします[...]

あいまいさがいくつかあります。 featureをrelease/v1.0.1にマージすること、またはrelease/v1.0.1をfeatureにマージすることを提案していますか？新機能をrelease/v.1.0.1に導入するには遅すぎるため、前者を行うべきではありません。それらは、将来のリリース、つまりafterv1.0.1で出荷される必要があります。左側のバブルを読みます。

enter image description here

また、後者も行わないでください。少なくとも、直接ではありません。上記で説明したように、release/v1.0.1からfeatureに変更を加えるには、最初にrelease/v1.0.1をdevelopにマージしてから、developをマージする必要がありますfeature;これは、featureをdevelopにマージする準備ができる前に、複数回発生する可能性があります。

補遺

Git Flowモデルに従っている場合は、

  1. 2つ以上のリリースブランチが共存していてはいけません。
  2. QAはリリース（別名stabilizing）ブランチのみをテストする必要があります。

したがって、他の機能がv1.1に組み込まれることになっている場合、QAに新しい機能の確認を依頼することはできません。他の機能が完了するまで待つ必要があります。 v1.1のすべての機能が完成してdevelopに統合されたら、release/v1.1ブランチを作成します（これはdevelopの頭から派生します）。次に、そのブランチのテスト/安定化を開始するようQAに依頼します。

一方、QAに独自の新機能のテストを依頼する前に、他の機能が完了するのを本当に待つことができない場合は、中間リリースブランチ（v1.0.2と呼ばれる）を作成する必要があります。 developをテストし、QAにrelease/v1.0.2をテストするように伝えます。十分に安定化したら、master（およびdevelop）にマージします。

24
jub0bs