我正在使用 NAnt 构建一个 ASP.NET MVC 项目。
然后，NAnt 脚本会创建一个 zip 包，其中包含一个部署脚本和所有必要的文件。
部署脚本备份当前正在运行的网站，设置新版本的网站并更新数据库。
这适用于单一环境。
但是，我们越来越多地被要求在生产旁边设置一个暂存/验收环境。当然，这些环境在文件结构、数据库服务器、配置设置等方面有所不同。
如何在部署脚本中最好地处理这个问题？我不想为每个环境创建单独的变量，只能通过名称区分。
提供默认值并在单独的文件中提供变量似乎更合乎逻辑。
有人有这方面的实际经验吗？
【问题讨论】：
标签： deployment build-automation nant packaging
将您认为可能在不同环境之间更改的内容存储在配置文件中。
如果您愿意，Visual Studio 可以在这里完成繁重的工作；您可以从 Visual Studio 项目属性的“设置”选项卡创建设置并指定默认值。
这将为您创建配置文件并通过Properties.Settings.Default 提供强类型访问。
至于通过构建处理多个环境，我看到一些人建议维护配置文件的多个副本 - 例如每个环境一个副本 - 其他人建议在构建或部署阶段使用 nant 修改配置文件.您可以在命令行（例如）使用传递给 nant 的属性来选择您正在构建（或部署，具体取决于您的操作方式）的环境。
我不推荐这两种方法，因为：
我创建每个配置文件的副本（例如称为 web.config.example）并注释掉其中的设置（除非它们具有有意义的默认值）。我将这些签入并让那些部署而不是真正的 web.config（也就是说，web.config 不会自动部署。web.config.example 被部署为 web.config.example。
新环境的管理员必须将文件复制并重命名为 web.config 并提供有意义的值）。我还将所有对设置的调用放在我自己的包装类后面 - 如果缺少强制设置，我会抛出异常。
构建和我的环境不再相互依赖 - 一个构建可以部署到任何环境。
如果缺少某个设置（新环境或现有环境中的新设置），那么您会收到一个很好的明确异常来告诉管理员该做什么。
升级后不会更改现有设置，因为仅更新了 .example 文件。将当前设置与最新示例进行比较并在必要时进行修改是一项管理任务。
要配置部署，您可以将所有环境设置（安装路径等）放入 nant 属性并将它们移动到单独的文件（例如 settings.build）中，然后使用 nant 包含任务将该文件包含在部署文件的顶部（例如，deploy.build）。然后，您可以部署新版本的 deploy.build，而不会覆盖您在 settings.build 中的配置更改。如果在 deploy.build 中引入了新属性，nant 将失败并显示一条好消息，告诉您您尚未设置该属性。
【讨论】：