Question

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

因此，链的高级概述是：

Web开发人员创建代码并在SVN中检查它;
Buildserver会看到更新并构建网站的msdeploy .zip包;
.zip包会自动放入我们的安装程序中并发送给各个客户端;
客户端在其Web服务器（-s）;
安装程序在内部使用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 |
                               --

是的，这确实意味着某种合并过程需要发生，并且需要有一些脚本可以做到这一点，但这种方法有几个优点。

对于突然变得多余的设置，只发出警告
如果客户拥有自己的徽标，则可以在覆盖文件
消息对客户来说很清楚。不要使用标准文件。
如果客户请求更多可自定义的设置，则在升级期间写入默认值（如果它不存在于覆盖文件中）。

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

至于你如何知道它的升级，你的脚本可以检查一个名为＆＃34; version.txt＆＃34;的文本文件。如果存在，则将运行升级bat脚本。要包含在文本文件中的版本。比特基本但它应该有用。

这还有一个额外的好处，即您可以更加优雅地合并客户在版本之间的自定义设置，因为您知道可以为该特定版本覆盖哪些属性。

Answer 2

有一些一般的建议（不是特定于msdeploy），但我希望有所帮助：

我认为您无论如何都需要提供多个安装程序：初始设置和每个版本到版本的升级。
我建议让您的客户自己合并配置文件。您可以为它们提供添加/更改/删除的详细说明，和/或包含简化合并的实用程序。也许this和this链接会给你一些指示。
至于合并替换后的徽标，其他客户端的自定义，我认为最好的方法是支持品牌推广您的应用程序。我的意思是 - 将所有品牌详情移至您的新/升级安装程序不会触及的位置。
至于您的客户进行的其他调整，他们自己承担风险，因此您可以提供的唯一帮助是包含更改的详细列表（甚至可能包含已更改文件的列表）自上一版本以来，以及有关使用Araxis Merge或类似工具合并来源的方法文章
或者..您可以创建一个实用程序并将其包含在安装程序中，安装程序将尝试在客户端计算机上执行所有棘手的合并操作。我不推荐这种方式，因为它需要很多努力/资源来维护。
还有一件事：您可以在升级之前专注于备份以前的客户端副本。因此，即使是客户也会遇到升级问题 - 总是可以回滚。这里唯一适合您的是提供一个良好的反馈渠道，您的客户可以使用它来解决他们的麻烦。通过此反馈，您可以了解客户遇到的问题以及如何使升级过程更加舒适。

Answer 3

我会建立在上面所说的内容之上，但我会用转换来做，并且有关谁配置什么的严格文档。您现在拥有它的方式依赖于客户干预对应用程序部署过程至关重要的配置。

创建三个配置文件区域。一个用于开发，一个用于“生产通用”构建，另一个用于客户编辑的空模板。

开发实例应该是自解释的。这是转换，它采用生产通用模板并为您的开发服务器创建Web配置。（这听起来像是你在这里拍摄CI类型的过程）
“生产通用”转换应该将应用程序设置为假设完美的应用程序实例。如果架构师按照自己的方式进行安装将会是这样的。
客户使用客户转换来根据需要设置Web配置以满足自己的需求。写一些文档，看看会发生什么。在您帮助客户完成整个过程时编辑文档。

那你在找什么？想法？

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

3 个答案: