用NAnt打包，如何处理不同的环境

Question

我正在使用NAnt构建一个ASP.NET MVC项目。

然后，NAnt脚本会创建一个zip包，其中包含部署脚本和所有必需的文件。

部署脚本备份当前正在运行的网站，设置较新版本的网站并更新数据库。

这适用于单个环境。

但是，我们越来越多地要求在制作旁边设置一个分段/接受环境。当然，这些环境在文件结构，数据库服务器，配置设置等方面有所不同。

如何在部署脚本中最好地处理此问题？我不想为每个环境创建单独的变量，只能按名称区分。

提供默认值并在单独的文件中提供变量似乎更合乎逻辑。

有没有人有这方面的实践经验？

Answer 1

将您认为可能在配置文件中的环境之间更改的内容存储起来。

如果你愿意，Visual Studio可以在这里做繁重的工作;您可以从Visual Studio项目属性的“设置”选项卡中创建设置并指定默认值。

这将为您创建配置文件，并通过Properties.Settings.Default提供强类型访问。

至于通过构建处理多个环境，我看到有些人建议维护配置文件的多个副本 - 例如每个环境一个 - 其他人建议在构建或部署阶段使用nant修改配置文件。您可以在命令行上使用传递给nant的属性（例如）来选择要构建的环境（或部署，具体取决于您的工作方式）。

我不推荐这两种方法中的任何一种，因为：

1. 他们都需要更改您的构建以支持新环境。
2. 如果更改已部署环境中的设置并忘记更新构建，则下一次部署将重置更改（稍微取消配置设置点）。
3. 如果有人创建了一个新环境（假设他们想要探索升级到新版本的SQL Server所引起的问题）并且不想在构建系统中创建所有新的配置文件，他们可能会决定只是使用现有环境的设置。假设他们选择使用实时设置进行部署，然后忘记更改内容。您的新“测试”环境现在可以指向live kit。

我创建了每个配置文件的副本（例如，称为web.config.example）并注释掉其中的设置（除非它们具有有意义的默认值）。我检查这些并将那些部署而不是真正的web.config（即，不会自动部署web.config。将web.config.example部署为web.config.example。

新环境的管理员必须将文件复制并重命名为web.config并提供有意义的值。我还将所有调用放在我自己的包装器类后面 - 如果缺少强制设置，我会抛出异常。

构建和我的环境不再相互依赖 - 可以将一个构建部署到任何环境。

如果缺少某个设置（新环境或现有环境中的新设置），您会收到一个很好的明确异常，告诉管理员该做什么。

升级后不会更改现有设置，因为只更新了.example文件。管理任务是将当前设置与最新示例进行比较，并在必要时进行修改。

要配置部署，您可以将所有环境设置（安装路径等）放入nant属性并将它们移动到单独的文件中（例如settings.build），然后使用nant include任务将该文件包含在部署文件的顶部（例如deploy.build）。然后，您可以部署新版本的deploy.build，而不会覆盖您在settings.build中的配置更改。如果在deploy.build中引入了一个新属性，则nant将失败并显示一条消息，告诉您尚未设置该属性。