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

因此,该链的高级概述是:


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


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

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

我不知道该怎么做。

除此之外,有时还有一些完全怪异的升级逻辑。例如,该应用程序带有我们公司的徽标,但是一些客户已替换该.png文件以显示其自己的徽标。最近,我们需要更新徽标-但仅适用于尚未将其替换为自己的徽标的客户。

同样,在某些升级过程中可能需要清理某些缓存文件夹,而在其他情况下则不需要清理。或包含用户内容可能不会被触及的文件夹(但在初始安装时带有默认内容)。等等。

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

最佳答案

个人经验建议:

隔离定制

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

> 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 |
                               --


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


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


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"


更多信息here

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

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

09-17 09:15
查看更多