如何使用Web部署(msdeploy)升级(合并)web.config？

Question

我正在尝试为我们的一些ASP.NET应用程序设置部署链.选择的工具是Web Deploy(msdeploy) - 目前.不幸的是我遇到了问题.

因此,链的高级概述是:

1. Web开发人员创建代码并在SVN中进行检查;
2. Buildserver看到更新并构建网站的msdeploy .zip包;
3. .zip包会自动放入我们的安装程序中并发送给各个客户端;
4. 客户端在其Web服务器上运行安装程序(-s);
5. 安装程序在内部使用msdeploy来部署.zip包并创建新网站或升级现有网站.

Msdeploy使部署新实例变得容易,但我对如何执行"升级"安装感到困惑.主要问题是web.config文件.每个客户端肯定会在那里进行一些自定义以适应他们的特定环境.安装程序本身可以在首次安装时设置一些更重要的参数(通过msdeploy的参数机制实现),但是他们可以手动执行其他操作.

另一方面,我们开发人员偶尔也会对web.config进行更改,添加一些新设置或删除过时的设置.所以我不能告诉msdeploy完全忽略该文件.我需要某种先进的XML修改机制.它可能是开发人员维护的脚本,但它只需要在升级时运行,而不是新安装.

我不知道如何做到这一点.

除此之外,有时还有一些完全奇怪的升级逻辑.例如,应用程序附带了我们公司的徽标,但是有些客户已经替换了.png文件来显示自己的徽标.最近我们需要更新徽标 - 但仅限于没有用自己的徽标替换它的客户.

同样,可能有一些缓存文件夹可能需要在某些升级时清除,而在其他升级时则不需要清除.或者包含可能无法触及的用户内容的文件夹(但在初始安装时带有默认内容).等等.

您通常如何为msdeploy包实现这种双重行为？我真的需要为每个应用程序创建2个不同的包吗？

Answer 1

个人经验建议：

隔离定制

您的客户应具有自定义设置的能力，最好的方法是为他们提供诸如替代文件之类的东西。这样，您可以安装新软件包，然后在标准设置的基础上叠加客户的自定义设置。如果是全新安装，则没有任何可叠加的内容。

> top-level             --
    > standard files      |
           images         | This will never be touched or changed by customer
           settings.txt   |
                        __
    > customer files           --
           images                | Customer hacks this to their heart's content
           settings.txt_override |
                               --

是的，这确实意味着需要进行某种合并过程，并且需要执行一些脚本来完成此合并，但是这种方法具有多个优点。

1. 对于突然变得多余的设置，只需发出警告就可以了
2. 如果客户有自己的徽标，则可以在替代文件中指定徽标
3. 该消息对客户很清楚。远离标准文件。
4. 如果客户要求更多可自定义的设置，则在升级过程中将默认值（如果不存在）写入替代文件中。

Vilx在回答您的问题时，必须在脚本本身中包含知道是否为升级的逻辑。

在安装之前运行升级脚本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat"

或在安装后运行升级脚本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat"

更多信息在这里

至于您如何知道其升级，您的脚本可以检查名为“ version.txt”的文本文件，如果存在，则将运行升级bat脚本。文本文件中包含的版本。有点基本，但应该可以。

这还具有额外的优势，使您能够更优雅地在版本之间合并客户的自定义设置，因为您知道可以为该特定版本覆盖哪些属性。

Answer 2

有一些一般性建议（并非特定于 msdeploy），但我希望有所帮助：

• 我认为您无论如何都需要提供多个安装程序：用于初始设置和每个版本到版本的升级。

• 我建议让您的客户自己合并配置文件。您可以只向他们提供添加/更改/删除内容的详细说明，和/或包含简化合并的实用程序。也许这个和这个链接会给你一些指示。

• 至于合并替换的徽标、其他客户的定制，我认为最好的方法是支持应用程序的品牌化。我的意思是 - 将所有品牌细节移至新/升级安装程序不会触及的地方。

• 至于您的客户所做的其余调整，他们需要自行承担风险，因此您可以为他们提供的唯一帮助是包括详细的更改列表（甚至可能是自上一版本以来更改的文件列表）和有关使用 Araxis Merge 或类似工具合并源的操作方法文章

• 或者..您可以创建一个实用程序并将其包含到安装程序中，该安装程序将尝试在客户端计算机上完成所有棘手的合并工作。我不会推荐这种方式，因为它需要大量的努力/资源来维护。

• 还有一件事：您可以在升级之前专注于备份以前的客户端副本。因此，即使是客户端也会遇到升级问题 - 总是有可能回滚。这里对你来说唯一的事情就是提供一个良好的反馈渠道，你的客户可以用它来解决他们的麻烦。此反馈将使您能够了解客户遇到的问题以及如何使他们的升级过程更加舒适。