プロセスに関しては、「標準プロセス」と比較してオプションのステップが 1 つだけ必要です。バグ (またはおそらく重大なバグ) を見つけた場合は、すべての変更 (つまり、バグを含むマージ) をロールバックします。
仕組みは次のとおりです。
開発ブランチからテスト中のブランチ、または略してBUTを作成します
フィーチャー ブランチは、開発ブランチに直接マージされるのではなく、テスト ブランチにマージされます。
現在、最後のリリースと同一であるか、このプロセスの最後の反復から十分にテストされているBUTがあります。
ここで、準備ができているすべての機能ブランチ / バグ修正をそのブランチにマージします。
あなたはそれをテストします。重大な問題が発生した場合、つまり、バグを含む機能/バグ修正が次のリリースに望ましくないものになる場合、リセットしてすべてのマージをやり直すか、リベースしてコミットを削除することにより、その機能のマージを元に戻します。同じ。これによりブランチの履歴が変更されるため、テストが完了する前にこのブランチを何かにマージしないでください。
テストの反復が正常に完了した場合 (つまり、大きなバグがなければ)、それを開発にマージします。
これが要件をどのように満たしているかを確認しましょう。
官僚主義を導入せずに展開できます (たとえば、毎月最終金曜日にリリース)。
以前と同じように、リリース ブランチがまだあります。ここでは問題ありません。唯一のオーバーヘッドは、バグが多い場合にマージを元に戻す必要があるかもしれないということですが、それを回避する方法がわかりません。
誰かがバグを導入しているコードをコミットしても、バグのないコードをコミットした他の誰かには影響しません。言い換えると、コーダー A が新しいバグを導入してバグを修正しようとし、コーダー B がバグを修正した場合、コーダー B のコードはさらにパイプラインに入り、コーダー A は遅れてバグを修正することになります。
小切手
無制限のテスト環境を持つことはできません。また、テスト環境のセットアップに 1 日を費やしたくありません。この要件を回避できるソリューションが必要です (何か不足していない限り、機能ブランチでのテストはオプションではありません)。
必要なテスト環境は 1 つだけです。複数のテスターの並行作業を容易にするために、より多くのことが役立つ場合があります。しかし、それはオプションです。
テスターは、何を製品化することを承認しているかを疑いなく正確に知っています。
機能ブランチが BUT の履歴の一部であるかどうかは、標準の git コマンドで非常に簡単に判断できます。これは必要なものです。
欠点・必要なもの
テスターによって承認されない限り、何も本番環境に移行したり、他の人々の作品とマージしたりすることはできません。これはプロセスのボトルネックになる可能性があります。特に機能ブランチからのものが低品質である場合はなおさらです。テスターがマージを解除する必要がある場合は、残りを再テストする必要があります (少なくとも、私が知っているテスターはそれを主張しますが、それには正当な理由があります)。そのため、バグによって速度が低下します (これは新しいことではありませんが、このようなプロセスでは非常に明白になります)。
この影響を制限するには、機能ブランチを可能な限り改善するために多大な努力を払う必要があります。
- BUT とマージする前に機能ブランチの自動テストを実行する
- BUT とのマージ後に機能ブランチの自動テストを実行する
- 良い自動テストがたくさんあります。
- コードレビュー
- ペアプログラミング
- テスト環境での展開を自動化する
基本的に、テスターがしなければならない作業の量を減らし、残りの作業を高速化するすべてのものが大いに役立ちます。
多くのテスト環境を持つことはできないとおっしゃいました。すべてのリソースを必要としないが、一部のテストには適している部分的なテスト環境を用意できるかどうかを検討してください。