VSTSリリース管理で複数の構成を処理する方法

Question

私たちのプロジェクトでは、コードとビルドを維持するためにVisual Studio Team Servicesを使用しています。このプロジェクトでは、リリース管理もセットアップします。（ https://www.visualstudio.com/en-us/features/release-management-vs.aspx ）

テスト、ステージング、および本番環境では、特定の環境用に変換されたさまざまなWeb.configファイルがあります。

私はそれを次のように設定しました（MSBuildビルド手順）：

クラウドサービスデプロイServiceConfiguration.cscfgとDeploymentPackage.cspkg（/ t：Publish）とターゲット環境テスト（/ p：TargetProfile = Test）
アーティファクトはVSTSビルドタスクで公開され、リリース管理での展開が可能になります。
夜間のビルドが成功すると、リリースが作成され、アーティファクトがダウンロードされて、テスト環境に自動的にデプロイされます。

問題は、リリースがテスト環境用にテストWeb.configとともに作成されていることです。このビルドをステージング環境に移行するための一般的なアプローチは何ですか？これにはステージングWeb.configが必要です。常に3回ビルドして、これらのアーティファクトを保持する必要がありますか？それは、ほとんどの場合デプロイされないビルドのための多くのアーティファクト/ディスクスペースを意味します。

MSDNは私に答えを与えていないようです。何か案は？

Philip Stratford · Accepted Answer

これが投稿されてほぼ1年になることはわかっていますが、私はこの同じ問題に対する答えを自分で理解しなければならなかったので、ここでそれを実行しました。 VSTSを使用しているため、オンプレミスのTFSとは少し異なる場合がありますが、わかりません。

1.ビルド定義で複数の構成を構成する

1.1ビルド定義を開いて編集します。

1.2 [変数]タブで、BuildConfiguration変数の値を編集し（存在しない場合はこの変数を追加します）、構築するさまざまな構成のコンマ区切りのリストになるようにします。これらの各値は、ソースコードの構成に対応している必要があります。この例では、Dev、Test、Stagingという3つの構成があります。私のコードでは、これらの構成のそれぞれに、異なるデータベース接続文字列などを指定する独自のweb.config変換ファイルがあります。

1.3 [オプション]タブで、右側の[マルチ構成]を有効にします。

1.4マルチ構成設定で、BuildConfiguration変数にMultipliers変数の名前を入力します。これは、ステップ1.2で値を設定した変数の名前と正確に一致する必要があります。私の例では、[Parallel]ボックスもオンにしたことがわかります。問題が発生した場合は、これをオフにすることができます。

1.5 [タスク]タブで、[ビルド]タスクを選択します。

1.6ビルドタスクのオプションで、出力ディレクトリにBuildConfiguration変数が含まれるように_MSBuild Arguments_フィールドを更新する必要があります。このようにして、ビルドタスクは構成ごとに個別の出力ディレクトリを作成します。このコンテキストでは、BuildConfiguration変数は$(BuildConfiguration)として指定されます。

1.7 [タスク]タブで、[アーティファクトの公開]タスクを選択します。

1.8 _Path to Publish_フィールドで指定されたパスにBuildConfiguration変数を追加します。これも、成果物がリリースプロセスで取得できるようにドロップされると、各構成に独自のサブフォルダーがあることを意味します。この場合も、BuildConfiguration変数は$(BuildConfiguration)として指定されます。

1.9 _Artifact Name_フィールドの値をBuildConfiguration変数に変更します。ここでも$(BuildConfiguration)です。

2.複数の構成のリリース定義を構成する

要件によっては、このビットは必要ないかもしれませんが、とりあえず含めます。これは、リリース定義で複数の環境を作成する方法で、それぞれがビルドプロセスとは異なる構成を使用しています。

2.1。編集するリリース定義を開きます。

2.2。「環境」タブで、構成する環境を選択します。この例では、Dev環境を構成しています。

ファイルのコピータスクを使用してWebアプリケーションを公開しています。別の方法を使用している可能性がありますが、別の方法を使用している場合は、これで正しい方向を示すのに十分でしょう。

2.3。ファイルのコピータスクを選択します。

2.4。 Sourceフィールドの値を変更して、構成している環境に適したビルド構成を含むサブフォルダーが含まれるようにします。

2.5。先に進んで、要件（マシン（ファイルの公開先のサーバー）など）に応じて、残りの環境設定を構成します。少なくとも_Destination Folder_フィールドは、環境ごとに必然的に異なります。。 Machinesフィールドも異なる場合があります。

新しいビルドをキューに入れるときにこのように見える場合、ビルドプロセスが複数の構成を正しくビルドしていることがわかります。左側にある複数の構成に注意してください。

これが他の誰かがこれを機能させるのに役立つことを願っています！

[〜＃〜] update [〜＃〜]上記のソリューションは完全にうまく機能しているようです。ただし、アプリケーションの1つを展開する環境の数が増えると（現在は10で数えています）、環境ごとに_Web.config_を変換する別の方法を探し始めました。環境間の実際の違いのみがデータベース接続文字列でした。

これが原因で、上記の解決策を放棄しました。代わりに、ビルドプロセスは、デバッグ属性を削除し、データベース接続文字列をトークン化されたバージョンに置き換える（環境ごとに1つではなく）_Web.config_変換を1つだけ使用するようになりました。デプロイメントプロセスによって入力されるトークン。

これはかなり整然としている。コードに_Web.config_変換が1つだけ含まれるようになり、各環境のビルドを生成しないため、ビルドプロセスがはるかに高速になり、データベースパスワードなどがリリース構成の変数として保存、暗号化されます。。

私がやったことの要点はこちらですが、その記事の著者は彼のオンプレミスTFSボックスにインストールされたTokenizerと呼ばれるツールを使用しているのに対し、私は私のWeb.configファイルで使用したトークンを変換するために、リリース構成のマーケットプレイスからの非常に素晴らしい Tokenization Task 。