一度構築してから、各環境の構成について読んでいます。たとえば、これを行う方法のいくつかのアイデアを次に示し ます。 msdeploy と Visual Studio 2012 を使用して、一度ビルドして複数の環境にデプロイする
私の質問は、これがビルド サーバーとどのように連携するかということです。複数の環境にデプロイする 1 つのビルドを開始した人はいますか? 各環境には、独自のルール/スケジュールを持つ独自のビルド定義があると思います。その場合、実際に一度構築することはどれくらい実現可能ですか? 私は何かが欠けているように感じます...
私はいつもこれをしています。一度ビルドして、環境ごとに再構成します。MSdeploy は使用しません。私は xdt テンプレート トランスフォームを使用します。これらはデプロイ時に環境プロパティと組み合わされます。ビルドにより、構成可能なパッケージが作成されます。
これにより、展開時にビジュアル スタジオが不要になります。複数の環境へのデプロイを開始できます。デプロイ時の新規/変更された環境もサポートできます。これは、msbuild、ctt ツールhttp://ctt.codeplex.com/documentation 、および msbuild 拡張パックの detokenisation タスクなどのトークン変換プロセスを使用して簡単に実現できます。このプロセスを構築すると、CI ツール (TFS ですが、Teamcity 用に ID を取得) および手動/cmdline/powershell でホストできます。
MSDeploy と Web パブリッシング パイプラインに基づくビルド パイプラインを使用していますが、MSBuild スクリプトで直接サポートされているシナリオではありません。
私が使用する基本的な前提は、ビルドの最初の「段階」でパッケージがビルドされ、その後、運用環境になるまでさまざまな環境にデプロイされるというものです。ビルド サーバーがクロスビルドの「アーティファクト」をどのように処理するかを調べる必要があります。
もう 1 つの問題は、発行プロファイルへのパッケージのデプロイが現在サポートされていないことです。ただし、コマンド ラインからパッケージを展開する (または、IIS 経由でインポートできる管理者にパッケージをアップロードする) という代替手段が常にあります。
これらのリソース (免責事項として、私自身のブログとコードへのリンクが含まれています) は次のことに役立ちます。