TFSビルドを使用する場合のリリース構成の管理
私が働いている組織は現在、Webデプロイを使用してさまざまな環境にリリースしています。 Webアプリケーションの構成（接続文字列、サービスURLなど）は、関連するapp.configトランスフォームとともにソリューション構成を使用して管理されます。デバッグ、3つのテスト環境、本番環境では、5つのソリューション構成（4つの変換）があります。環境にデプロイする場合、Webデプロイは選択した構成に対してソリューションを構築し、適切な変換を使用してそれをデプロイします。
より洗練されたビルドおよびリリース管理プロセスを使用するように私は私を移動しようとしています。同社はMicrosoftツールを使用することにかなり慣れており、TFSビルド2015（オンプレミス）を使用することに同意しています。
現在のプロセスは、CI/CDアプローチおよびTFSリリース管理と組み合わせて使用するのには適さないようです。あるソリューション構成でテストされたビルドを再構築して、別のソリューション構成でプロモートする必要があるとは思いません。もう1つの懸念は、これはメンテナンスが重くなり、個別のビルド定義が必要になるため、環境ごとにリリース定義が必要になることです。
2つのソリューション構成のみを使用することを想定しています（デバッグとリリース）。開発ブランチにチェックインすると、デバッグ構成を使用してCIビルドが自動的に開始されます。まず、リリースモードでの手動ビルドが必要です。次に、リリース定義を使用して、このビルドを必要に応じて関連するアプリケーション構成を持つ各環境にプロモートできます。
最終的には、テストの最初の段階（リリースブランチへのマージなど）への展開を自動化することが目標になります。自動テストを実行するための環境に展開する3番目のソリューション構成のケータリングに拡張することも役立つ場合があります。
私の質問は：
- 環境ごとに再構築しないことが望ましいと私は信じていますか？
- これは私の目的を達成するための適切なアプローチですか、それとも別の/より良いアプローチを見逃していますか？
- このアプローチに従う場合、ビルドにデバッグ/リリースを使用し、リリースジョブの一部として変換するだけで、ソリューション構成を（app.configトランスフォーム用に）そのままにしておくことが望ましいと考えられますか？または、リリース定義の環境変数を使用して構成を管理する方が良いですか（構成の集中管理はありません）。
私はあなたが正しい軌道に乗っていると思います。
環境ごとに再構築しないことが望ましいと私は信じていますか？
あなたは正しいです。一度ビルドして、各環境に同じ成果物をデプロイし、構成データのみを変更する必要があります。
これは私の目的を達成するための適切なアプローチですか、それとも別の/より良いアプローチを見逃していますか？
私の意見では、あなたが説明したこと（2つのソリューション構成、関連するアプリケーション構成でのビルドの促進）は良いソリューションです。
このアプローチに従う場合、ビルドにデバッグ/リリースを使用し、リリースジョブの一部として変換するだけで、ソリューション構成を（app.configトランスフォーム用に）そのままにしておくことが望ましいと考えられますか？または、リリース定義の環境変数を使用して構成を管理する方が良いですか（構成の集中管理はありません）。
デバッグとリリースの構成をそのままにしておくのは問題ないと思います。可変グループを使用するか、環境固有の構成ファイルを安全な場所に単純に保存して、リリース中に必要に応じてプルすることができます。メンテナンスしやすいものを使用してください。