2011-12-20 45 views
3

我知道有很多像这样的问题,但迄今为止我还没有找到一个好的解决方案。我见过的最好的解决方案是自制的,但在实施自定义工具之前,我想听听你的看法。所以我们去:使用不同的app.config设置自动部署到许多服务器?

我有一个.NET解决方案与几个Web应用程序和一些Windows服务。我想将这些应用程序部署到10-20个不同的服务器上 - 但每个服务器上的app/web.config文件可能有不同的值。

微软对这个问题的回答是在开发机器本地有10-20个不同的web.config文件,然后使用配置管理器来选择正确的。但这还不够好,因为开发人员不了解生产服务器设置,他们也不应该这样做!

理想的解决方案是包含某种类型的“部署模型”,其中生产服务器及其设置已定义,并且可以与某些部署脚本(可能为Powershell)一起用作构建中的一个步骤服务器(我正在使用TeamCity)。这可以通过在将解决方案复制到远程服务器之前替换配置设置来完成。但这是一项繁琐耗时的任务。

另一种解决方案可能是使用“configSource”指向一个固定名称的文件夹,但这里的问题是配置文件的某些部分(如serviceModel)不能与configSource一起使用。

所以我还没有找到最好的答案。有任何想法吗?

+0

什么(其他)工具,你起诉?新的软件包管道? – 2011-12-20 11:31:37

+0

那么我一直在使用的一些工具是:VS2010 - > SVN - > MSBuild - > TeamCity - >用于部署的自定义PS脚本。因为我有Web应用程序和Windows服务,所以我没有使用WebDeploy。 – lasseschou 2011-12-20 12:04:19

+0

查看InRelease,它与TFS的整合比TeamC更好,但可能仍然可以用来解决您的问题(我是该产品的开发者):http://inrelease.incyclesoftware.com – joerage 2011-12-20 16:09:53

回答

1

我们的部署模型的一部分(也是TeamCity集中构建到多个不同的服务器)是自动创建部署脚本作为MSBUILD文件的一部分,并将部署基于MSDEPLOY/web部署2.0进行部署。

该构建会自动生成适合使用MSDEPLOY进行部署的构建候选项,并且还会敲出将选择相应配置文件并将其复制到位的powershell/cmd scriptlet。

对所有服务器的部署就成为将这些单独部署脚本串在一起(即使用批处理文件)的情况。由于MSDEPLOY只发送了文件更改它通常相当迅速,并且可以用来进行备份以及做部署,从而部署脚本它将部分:

  1. 采取相应服务器的备份(如WEB1),并把它贴在转换的任何文件作为必要的网络共享
  2. 部署相应的包到服务器(WEB1)(例如Web.Web1.Config - > Web.config文件)
  3. 写任何必要的日志

构建过程还吐出一个'撤销'脚本,将恢复e适当的服务器到备份。

还有更多的MSDEPLOY here。它也可以与数据库等

只是一个建议使用,它可能会有所帮助:)

+0

我知道这是几个月前,但我把这个标记为让我朝着正确方向的答案。谢谢! – lasseschou 2012-07-31 12:07:39

0

[Blatant vendor post]我们在我们的uDeploy产品中正好使用这种部署模型。

其基本思想是定义一个单独的部署过程,其中包括更新配置文件的步骤(app.config和web.config是ASP应用程序最常用的)。这些差异可以是每个服务器或每个逻辑环境(dev test,qa,stage,prod ...)。或者,您可以直接在uDeploy中放置模板app.config文件,然后在部署时写出它。

工具integrates with TeamCity检索构建以及用于部署和配置应用程序池和服务器的IIS。它还设计用于跟踪TeamCity构建的多个服务和Web应用程序的不同之处,并将其作为发布集合使用。

从表面上看,这听起来像我们可能有一个体面的适合。请随时直接通过[email protected]与我联系。干杯! [/ blatant厂商帖子]

0

我使用XmlPreprocess tool进行配置文件操作。它为多个环境/服务器使用一个映射文件。您可以通过Excel编辑映射文件。这是非常容易使用。 在自定义PS脚本中调用XmlPreprocess,并将服务器名称作为环境参数传递。

相关问题