39

複数のソリューションの構成、アプリ設定、接続文字列の集中化に取り組んでいると同時に、コマンドラインからmsdeployを使用してWebアプリをデプロイするように切り替えています。理想的には、パッケージを一度ビルドし、パッケージが各環境にデプロイされるときに最新の構成を取得したいと思います。最善のアプローチについてアドバイスが必要です。

  1. Parameters.xmlおよびSetParameters.xmlファイルを使用して、設定と接続文字列を動的に交換します。http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.htmlを参照してください
  2. machine.configまたはサーバーレベルのweb.configファイルを使用して、一般的なアプリ設定と接続文字列を保存します。
  3. https://github.com/sayedihashimi/package-webのpackagewebNuGetパッケージを使用して、msdeployでweb.config変換を使用できるようにします。
  4. ファイルまたはconfigSource属性をSetParametersとともに使用して、異なる構成ファイルをポイントしますが、Webルートからの相対的なものである必要があります。
  5. 公開プロファイルを使用します。公開プロファイルを使用した既存のパッケージのデプロイを参照し てください

ありがとう

4

4 に答える 4

20

オプション#1 /#3について少し詳しく説明し、それらを比較することができます。前の回答は、PackageWebで複数回ビルドする必要があるという点で正確ではなく、1回だけビルドする必要があります。

オプション1:Parameters.xmlおよびSetParameters.xml

このアプローチでは、追加のWeb配置パラメーターを宣言するparameters.xmlファイルをWebプロジェクトに作成します。

Web配置パッケージをビルドすると、parameters.xmlで宣言されたパラメーターがパッケージに作成されます。このWebデプロイパッケージが作成されると、web.configファイルはビルド構成に基づいて変換されます(現在はプロファイル固有の変換も可能です)。

そのパッケージとsetparameters.xmlを使用して、Web配置パラメーター値を指定するパッケージを公開できます。さまざまなsetparameters.xmlファイルを作成し、それを同じパッケージと一緒に使用して、複数の宛先に公開できます。この手法を使用して公開するには、VSが生成するdeploy.cmdを使用するか、正しいパラメーターのセットを使用してmsdeploy.exeを呼び出します。

オプション3:PackageWeb

PackageWebは、パッケージプロセスを拡張して、Web配置パッケージを作成するときに、web.config変換がパッケージと、変換を実行できるアセンブリに含まれるようにします。

これに加えて、Webデプロイパッケージを作成すると、publish-interactive.ps1ファイルが生成されます。このファイルを使用して、パッケージを公開できます。プロンプトが表示されます。適用されるweb.config変換、Web配置パラメーター値、およびWeb配置エンドポイント情報自体。公開を実行すると、指定した値がに保存されpublish-configuration.ps1.readmeます。.readmeを削除すると、publish-interactive.ps1はそのファイルの値を使用して公開を自動化します。設定に使用するファイルを指定することもできます。

Web配置パッケージがVSによって作成されたときにparameters.xmlファイルを作成した場合、その結果、Web配置パラメーターがパッケージに含まれます。PackageWebはそれらをピックアップし、それらについてもプロンプトを表示します。

では、これらのアプローチの違いは何ですか?

オプション#1では、パッケージに含まれるweb.configはすでに変換されています。ファイルを再度変換する機会はありません。どちらのアプローチでも、ニーズに合うようにWebデプロイパラメータ値を指定できます。XMLの大きなチャンクをある環境から別の環境に変更する場合は、web.config変換が役立つ場合があります。したがって、PackageWebの方が適している可能性があります。

オプション#1では、SetParameters.xmlファイルを手動で作成する必要があります。PackageWebを使用すると、WhatIfオプションを使用してプロセスを実行できます。値の入力を求められ、設定ファイルが作成されます。

両方のアプローチを簡単に自動化できます。PackageWebは、基本的にparameters.xml / setparameters.xml手法に基づいて構築されており、機能のスーパーセットを提供します。

可動部品の数を最小限に抑えて物事をできるだけシンプルにしたい場合は、必要に応じてmsdeploy.exeを直接呼び出すことができるため、オプション#1をお勧めします。

公開の自動化を簡素化し、標準のコマンドプロンプトよりもPowerShellを使用したい場合は、PackageWebを試してください。

PackageWebのhttp://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspxに5分間のビデオがあります。Webデプロイパッケージを公開している場合は、試してみることをお勧めします。それがあなたのニーズを満たさない場合は、私たちが後でPackageWebで学んだことをより正式な方法で使用する可能性があるので、私に知らせてください。

于 2012-11-11T22:04:50.883 に答える
8

オプション#1を使用すると、十分に機能します。このアプローチを使用して、約30〜40のサイトとアプリケーションに展開します。

オプション#2は、あなたまたは開発者のどちらにも頭痛の種になると思います。設定のあるセクションが展開時に構成から削除されていることを確認するか、ローカル構成がそれらを追加できないようにサーバーでそれらをロックする必要があります。

オプション#3の場合、変換された構成ファイルを取得するには、複数のビルドを実行する必要があります。また、展開するサイトが多数ある場合は、あまり実現可能ではありません。

オプション#4は機能する可能性がありますが、ここで制限に遭遇する可能性があります。セクション全体が別のファイルにあるか、すべてがメインファイルにあるため、間にはありません。

オプション#5は面白そうに見えますが、私はそれを使用したことがないので、それについて多くを語ることはできません。

于 2012-11-06T19:47:20.430 に答える
5

#5を使用しており、非常にうまく機能します。プロファイルの公開にMSBuildを使用すると、多くの柔軟性が得られます(アイテムは特に便利です)。

デプロイメントパイプラインでは、Webサイトパッケージ、ビルド/採用ターゲット、および公開プロファイルのみがデプロイメントステージで利用可能になります。プロジェクトファイルを含むソースコードは、ビルド/テスト段階でのみ使用されます。

参考までに、環境固有のサーバーの詳細/クレデンシャル、スキップ句、およびパラメーター値を一緒に保持するという問題にすぐに遭遇するため、特に公開プロファイルを使用しました。WPP / Publish Profilesは、ファイル内のこれらすべてのものを追跡しpubxmlます。MSBuildの機能により、一般的ではあるが「ノイズの多い」タスクに対して、設定より規約の「ヘルパー」を使用できます。

于 2012-11-11T23:14:04.463 に答える
3

最終的に、TeamCityで実行されているmsbuildを組み合わせて、OctopusDeployで使用できるNuGetパッケージを作成することでこの問題を解決しまし

Octopusを使用すると、nugetパッケージ(1回作成)にパッケージ化されたアプリケーションを複数の環境にプッシュできます。構成は、標準のms変換を使用して、環境ごと、またはマシンごとに変換できます。以下の関連するOctopusドキュメントへのリンク。

タコの包装

構成変換の構成

于 2014-10-15T23:16:01.447 に答える