用NAnt打包，如何处理不同的环境
我正在使用 NAnt 构建 ASP.NET MVC 项目。
然后，NAnt 脚本创建一个 zip 包，其中包含部署脚本和所有必需的文件。
部署脚本备份当前正在运行的网站，设置网站的新版本并更新数据库。
这对于单一环境来说效果很好。
然而，我们越来越多地被要求在生产旁边建立一个暂存/验收环境。当然，这些环境在文件结构、数据库服务器、配置设置等方面有所不同。
我如何在部署脚本中最好地处理这个问题？我不想为每个环境创建单独的变量，仅通过名称来区分。
提供默认值并在单独的文件中提供变量似乎更合乎逻辑。
有人有这方面的实际经验吗？
I'm using NAnt to build an ASP.NET MVC project.
The NAnt script then creates a zip package, containing a deploy script and all the necessary files.
The deploy script backs up the current running website, sets up the newer version of the website and updates the DB.
This works fine for a single environment.
However, we're asked more and more to set up a Staging/Acceptance environment next to the production. These environments, of course, differ in file structure, DB server, config settings etc.
How can I best handle this in the deploy scripts? I don't want to create separate variables for each environment, distinguishable by name only.
Providing defaults and providing the variables in separate files seems more logical.
Does anyone have practical experiences with this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将您认为可能在配置文件中的环境之间发生变化的内容存储起来。
如果您愿意，Visual Studio 可以在这里完成繁重的工作；您可以从 Visual Studio 项目属性的“设置”选项卡创建设置并指定默认值。
这将为您创建配置文件，并通过 属性.设置.默认。
至于通过构建处理多个环境，我看到有些人建议维护配置文件的多个副本 - 例如每个环境一个 - 而其他人建议在构建或部署阶段使用 nant 修改配置文件。您可以使用在命令行上传递给 nant 的属性（例如）来选择您正在构建（或部署，具体取决于您的操作方式）的环境。
我不推荐这两种方法，因为：
我创建每个配置文件的副本（例如，称为 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将失败并显示一条友好消息，告诉您尚未设置该属性。
Store the things that you think are likely to change between environments in config files.
Visual Studio can do the heavy lifting here if you like; you can create settings and specify default values from the Settings tab of a Visual Studio project's properties.
This will create the config file for you and provide strongly-typed access through Properties.Settings.Default.
As for handling multiple environments through your build, I've seen some people recommend maintaining multiple copies of the config files - one for each environment for example - and others recommend using nant to modify the config files during the build or deployment phase. You can use a property passed to nant on the command line (for example) to select which environment you are building (or deploying, depending on how you're doing it).
I don't recommend either of these approaches because:
I create a copy of each config file (called web.config.example, for example) and comment out the settings within them (unless they have meaningful defaults). I check these in and have those deployed instead of the real web.config (that is, web.config is NOT deployed automatically. web.config.example is deployed as web.config.example.
The admin of the new environment will have to copy and rename the file to web.config and provide meaningful values). I also put all the calls to the settings behind my own wrapper class - if a mandatory setting is missing I throw an exception.
The build and my environments no longer depend on each other - one build can be deployed to any environment.
If a setting is missing (a new environment or a new setting in an existing environment) then you get a nice clear exception raised to tell the admin what to do.
Existing settings are not altered after an upgrade because only the .example files were updated. It's an admin task to compare the current settings with the latest example and revise if necessary.
To configure the deployment, you could put all the environmental settings (install paths, etc) into nant properties and move them into a separate file (settings.build for example) then use the nant include task to include that file at the top of your deployment file (deploy.build for example). You can then deploy a new version of deploy.build without overwriting your config changes as they are in settings.build. If a new property is introduced into deploy.build nant will fail with a nice message to tell you that you haven't set that property.