TFSを使用すると、次のようになります。
問題は、ビジネスアナリストがテストサーバーにアクセスするまで変更を確認できないことです。現在、テストサーバーで変更を取得する唯一の方法は、変更をベースラインにチェックインすることです。したがって、BAが何か問題を見つけた場合、残念ながら、コードはすでにベースラインにあり、それを元に戻すという問題を経験する必要があります。
ベースラインを汚染することなく、BAが見たいものを取得するために、分岐戦略またはプロセスを変更する方法はありますか？
あなたのブランチ戦略は、私たちが私の会社で決めたものとまったく同じです。問題はブランチ戦略にあるとは思いません。問題は、変更をテストサーバーに適用するために、ベースラインへの変更をチェックする必要があることだと思います。
私の会社では、変更がプロモートされて本番環境で実行されるまで、変更はベースラインにチェックインされません。リリースブランチは、テストサーバーにデプロイされるものです...バグが見つかった場合、またはBAが何かを変更したい場合は、ベースラインから変更を削除するという苦痛を経験する必要はありません。
ただし、同時リリースが多数ある場合は、プロセスの後半までベースラインにマージしないため、すべてのリリースを本番環境に移行する前にマージするのは面倒な場合があります。私の会社では、リリーススケジュールが非常に厳しく、一度に1つのリリースだけが本番環境に移行するようにしています。このため、リリースが本番環境にプロモートされるまでリリースをベースラインにマージするのを待っても、これまでのところ問題や追加の作業は発生していません...
どのくらいの頻度でリリースを行いますか？リリースブランチをテストサーバーにデプロイし、ベースラインに現在本番環境にデプロイされているものを表すことができますか？
（私はこれをコメントしますが、私はまだその特権を獲得するために取り組んでいます...）
私はこのアプローチを好まないでしょう、私は提案します：
安定化されたコードを含むメインベースライン。コードは、リリースが成功した後にのみ、それぞれのリリースブランチからこのブランチにマージされます。
リリースごとにメインから作成されるリリースブランチ。このブランチはリリースビルドを生成するために使用され、テスト環境にデプロイされます。
リリースブランチから作成された開発ブランチは、開発作業に使用され、ビルドをテストする準備ができたときにリリースにマージされます。