我知道在SO上有很多这样的问题,但到目前为止我还没有找到一个好的解决方案。我见过的最好的解决方案是自制的,但在实现自定义工具之前,我想听听你的看法。所以我们走了:
我有一个带有几个Web应用程序和一些Windows服务的.NET解决方案。我想自动将这些应用程序部署到10-20个不同的服务器 - 但每个服务器上的app / web.config文件可能有不同的值。
Microsoft对此问题的回答是在开发计算机上本地拥有10-20个不同的web.config文件,然后使用配置管理器选择正确的文件。但这还不够好,因为开发人员不了解生产服务器设置,也不应该知道!
理想的解决方案是包含某种“部署模型”,其中定义了生产服务器及其设置,并且可以与某些部署脚本(可能是Powershell
)一起使用,作为构建服务器(我正在使用TeamCity
)。这可以通过在将解决方案XCopying到远程服务器之前替换配置设置来完成。但这是一项繁琐而耗时的任务。
另一种解决方案可能是使用“configSource”指向具有固定名称的文件夹,但问题是配置文件的某些部分(例如serviceModel)不能与configSource一起使用。
所以我没有找到最好的答案。有什么想法吗?
答案 0 :(得分:1)
部分部署模型(也是部署到许多不同服务器的TeamCity集中构建)是自动创建部署脚本作为MSBUILD文件的一部分,并以MSDEPLOY / Web部署2.0为基础进行部署。
构建将自动生成适合与MSDEPLOY一起部署的构建候选者,并且还会敲出一个powershell / cmd scriptlet,它将选择适当的配置文件并将其复制到位。
然后,对所有服务器的部署就变成了将这些单独的部署脚本串联在一起的情况(即使用批处理文件)。由于MSDEPLOY仅发送文件更改,因此通常非常快速,并且可以用于备份和部署,因此作为部署脚本的一部分,它将:
构建过程还会发出“撤消”脚本,该脚本会将相应的服务器还原到备份中。
MSDEPLOY here还有更多内容。它也可以用于数据库等。
只是一个建议,它可能会有所帮助:)
答案 1 :(得分:0)
[Blatant vendor post]我们在uDeploy产品中使用了这种部署模型。
基本思想是定义单个部署过程,其中包括更新配置文件的步骤(app.config和web.config是ASP应用程序最常用的)。这些差异可以是每个服务器或每个逻辑环境(开发测试,qa,阶段,产品......)。或者,您可以将模板app.config文件直接放在uDeploy中,我们会在部署时将其写出来。
用于检索构建的工具integrates with TeamCity以及用于部署和配置应用程序池和服务器的IIS。它还旨在跟踪可能与TeamCity不同的多个服务和Web应用程序如何组合在一起作为发布集。
从表面上看,听起来我们可能有一个合适的选择。请随时通过eric@urbancode.com与我联系。干杯! [/明显的供应商帖子]
答案 2 :(得分:0)
我正在使用XmlPreprocess tool进行配置文件操作。它使用一个映射文件用于多个环境/服务器。您可以通过Excel编辑映射文件。这是非常容易使用。 在自定义PS脚本中调用XmlPreprocess并将服务器名称作为环境参数传递。