gitflowを使用して、リリースブランチを閉じる傾向があるのはいつですか？
私たちはgitflow分岐戦略を使用しており、うまく機能します。私が見つけられないように見えるのは、人々がリリースをクローズする時点についての推奨です。
たとえば、4つの環境があるとします。
developtestuatproduction
develop環境での機能の選択に取り組んでおり、現在develop、v1.0.0からのリリースを作成しています。
そのため、バグが発生したtest環境にv1.0.0を取り込み、リリースブランチで修正することができます。 QAはリリースに合格し、クライアントがuatに進む前にサインオフできるように、それをproductionに移したいと考えています。
このプロセスのどこでリリースブランチを閉じるのですか？ testからuatに移動したとき、またはuatからproductionに移動したときは？
ほとんどの人が使用する標準はありますか、それともプロジェクトに適したものですか？私にとっては、各オプションの長所と短所があります。 TBH testからuatに変更することで、リリースを閉じることのメリットが大きくなりますが、クライアントがサインオフしてリリースされるまで、リリースを開いたままにしますto productionは非常に理にかなっています。
私の経験では、masterブランチは常に本番環境に対応している必要があります。 UATが行われる前に変更をマスターにマージする場合、実際にそれらの変更が本番環境に移行することを承認していないため、masterブランチが本番環境に対応しているとは限りません。実際、これは公式にはgit flowの要件です。
https://nvie.com/posts/a-successful-git-branching-model/ から
Origin/masterをメインブランチと見なし、HEADのソースコードは常に本番環境の準備状態を反映しています。
リリースブランチをUATのマスターにマージし、偶然に本番環境が完全にクラッシュし、再利用する必要がある場合はどうなりますか？検証されていない変更を本番環境にデプロイしますか、またはマスターの最新の適切なコミットから手動で分岐して、間違ったコードをデプロイするリスクがありますか？コミットを選択してデプロイブランチを作成することは、gitの知識が中程度の人にとってはかなり簡単ですが、ブランチがデプロイに適していることを管理者に納得させることは、まったく異なる話になる可能性があります。 「マスターは常にプロダクションに行くのが良い」と断言できれば、はるかに簡単です。
UATを介してプロダクションアーティファクトを入れないことに関するEwanの回答のコメントでの懸念について：onlyマージの一貫したワークフローをマスターにリリースし、マスターへの直接のプッシュを許可しない場合、これが問題になることはほとんどありません。通常の機能レビューと同じように、（私の意見では、）すべてのリリースをコードレビューすることもできます->マスターマージ。
構築するソフトウェアシステムの種類によって異なります。たとえば、本番環境で1つのバージョンのみをサポートするマルチテナントSaaSソリューションは、複数のバージョンを同時にサポートする可能性のあるあらゆるタイプのソフトウェアシステムとは異なります。
システムのタイプに関係なく、バージョンがサポートされなくなるまでリリースブランチを閉じない傾向があります。これにより、サポートされているすべてのバージョンに修正プログラムを適用して、新しいリリースを作成できます。適切なタグ付け（マスターブランチでリリースにタグ付けするなど）を使用している場合は、任意のタグを開始点としてブランチを作成できますが、ブランチが存在する方が簡単です。
バージョンをサポートすることによってそれが何を意味するかを定義するのはあなた次第です。
ほとんどの人は開発ブランチをテストすることを好むと思います。
機能ブランチでテストする場合、一度に開発されるさまざまな機能すべてに対してn個の環境が必要であり、これは面倒です。
開発のテストが完了し、デプロイメントにUATフェーズがある場合、UAT環境でリリースブランチをテストすることは理にかなっています。おそらく次のリリースのテストは、test envおよび開発ブランチを使用して続行されます。
UATが完了したら、リリースをマスターにマージし、これを本番環境にデプロイします。
私の見解では、ここには少しジレンマがあります。テストに合格したまったく同じバイナリをリリースしたいと思います。しかし、私はまた、マスターにある正確なコードをリリースしたいと思います。
理論的には、マージ前のリリースはマージ後のマスターと同じです。しかし、実際にはそうではないかもしれません。