我正在尝试为一些ASP.NET应用程序设置部署链。目前选择的工具是Web Deploy（msdeploy）。不幸的是，我遇到了一个问题。
因此，链的高级概述是：
- Web开发人员创建代码并在SVN中进行检查
- Buildserver看到更新并构建网站的msdeploy.zip包
- .zip包会自动放入我们的安装程序中，并发送到各个客户端
- 客户端在其Web服务器上运行安装程序
- 安装程序在内部使用msdeploy来部署.zip包并创建新网站或升级现有网站
Msdeploy使部署新实例变得容易，但我对如何执行"升级"安装感到困惑。主要问题是web.config文件。每个客户肯定都会在那里进行一些定制，以适应他们的特定环境。安装程序本身提供在第一次安装时设置一些更关键的参数（通过msdeploy的参数机制实现），但他们可以手动设置其他参数。
另一方面，我们开发人员偶尔也会对web.config进行更改，添加一些新设置或删除过时的设置。所以我不能告诉msdeploy完全忽略这个文件。我需要某种高级的XML修改机制。它可以是开发人员维护的脚本，但它只需要在升级时运行，而不是在新安装时运行。
我不知道如何做到这一点。
除此之外，有时还有一些完全奇怪的升级逻辑。例如，该应用程序带有我们公司的徽标，但一些客户已经替换了.png文件以显示他们自己的徽标。最近，我们需要更新徽标，但仅限于那些没有用自己的徽标替换的客户。
类似地，可能有一些缓存文件夹在某些升级时需要清理，但在其他升级时则不需要。或者包含可能无法触摸的用户内容的文件夹（但在初始安装时带有默认内容）。等等
对于msdeploy包，您通常是如何实现这种双重行为的？我真的需要为每个应用程序创建两个不同的包吗？
个人经验建议：
隔离自定义
您的客户应该能够自定义他们的设置，最好的方法是为他们提供类似覆盖文件的东西。这样，您就可以安装新的软件包，然后将客户的定制内容叠加在标准设置之上。如果这是一个全新的安装，那么就没有什么可叠加的了。
> 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 |
--
是的，这确实意味着需要进行某种合并过程，并且需要一些脚本来实现这一点，但这种方法有几个优点。
- 对于突然变得多余的设置，只需发出相应的警告
- 如果客户有自己的徽标，则可以在替代文件中指定
- 客户清楚地看到了这一信息。远离标准文件
- 如果客户要求更多可自定义设置，则在升级期间将不存在的默认设置写入覆盖文件
维尔克斯，在回答你的问题时，知道它是否是升级的逻辑必须包含在脚本本身中。
在安装之前运行升级脚本
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"的文本文件，如果它存在，升级蝙蝠脚本就会运行。要包含在文本文件中的版本。有点基础，但应该可以。
这还有一个额外的优势，即您可以更优雅地在版本之间合并客户的自定义设置，因为您知道特定版本可以覆盖哪些属性。
有一些一般性的建议（不是针对msdeploy的），但我希望这有帮助：
-
我认为您无论如何都需要提供几个安装程序：用于初始安装和每个版本到版本的升级。
-
我建议让你的客户端自己合并配置文件。您可以向他们提供添加/更改/删除内容的详细描述，和/或包括简化合并的实用程序。也许这个和这个链接会给你一些提示。
-
至于合并被替换的徽标，其他客户的定制，我认为最好的方法是支持你的应用程序品牌化。我的意思是，将所有品牌细节转移到你的新/升级安装程序不会触及的地方。
-
至于你的客户所做的其余调整，他们自己承担风险，所以你能为他们提供的唯一帮助是包括详细的更改列表（甚至可能是自上一版本以来更改的文件列表）和关于如何使用Araxis Merge或类似等工具合并源的文章
-
或者。。您可以创建一个实用程序并将其包含在安装程序中，安装程序将尝试在客户端的机器上完成所有棘手的合并操作。我不建议这样做，因为它需要大量的努力/资源来维护。
-
还有一件事：在升级之前，您可以专注于备份以前的客户端副本。因此，即使是客户端也会遇到升级问题——这总是有可能回滚的。这里对你来说唯一的事情就是提供一个好的反馈渠道，你的客户可以用它来解决他们的问题。这些反馈将使您能够了解客户遇到的问题，以及如何让他们的升级过程更加舒适。
我会在上面所说的基础上进行构建，但我会通过转换和关于谁配置什么的严格文档来实现。现在的方式依赖于客户对应用程序部署过程至关重要的配置的干预。
创建三个配置文件区域。一个用于开发，一个用于"生产通用"构建，还有一个是供客户编辑的空模板。
- 开发实例应该是不言自明的。这是一个转换，它采用生产通用模板并为开发服务器创建一个web配置。（听起来你是在为CI类型的流程拍摄）
- "生产通用"转换应该为应用程序设置一个假设完美的实例。如果建筑师有自己的方式，安装会是这样的
- 客户转换由客户用于根据需要设置web配置，以满足他们自己的需求。写一些文档，看看会发生什么。在帮助客户完成流程时编辑文档
这就是你想要的吗？想法？