如何实现.NET部署Nirvana?

Jac*_*cob 5 .net configuration production-environment

我们的公司已经接近其"上线"日期(以及获得QA部门日期),我正在尝试定义正确的操作流程来支持这一点.我的一个重要考虑因素是如何避免不可避免地发生的部署/配置问题.有没有人找到一个很好的解决方案,将构建交给非程序员,以便他们可以在QA,登台和生产环境中成功安装和配置它?

我们的完整环境由异构计划任务,Windows服务和网站组成,所有这些都可以通过并行部署进行扩展.值得庆幸的是,配置方式是一致的.不幸的是,它都通过.NET web/app.config文件进行管理.根据我的经验,QA和操作人员在尝试修改它们时总是陷入困境(对于大多数人来说,XML难以处理!)

这是我正在考虑的选项:

使用machine.config文件

这是我在实践中没有做过的事情,但看起来很有希望.如果我们创建一个machine.config模板,其中包含可能因环境而异的每个应用程序的每个设置,这将允许管理员对一个文件进行所有更改并将其部署到环境中的每台计算机.

优点:
这可能会减少部署系统所需的步骤数
缺点:
必须以某种方式记录配置架构更改
未知数:
我们使用自定义配置节和其他引用程序集的配置扩展.这是否需要我们在机器的GAC中安装.NET程序集?

在构建过程中执行配置文件操作

如果我们设置QA,登台和生产环境,使它们看起来与我们的软件(虚拟服务器和LAN等)完全相同,那么QA应该能够将没有配置更改的现成软件直接转换到登台环境,并进入生产阶段.通过这种设置,理论上我们可以将QA预先配置的foo.config文件交给无人接触的文件.

优点:
工程部门将更擅长确保配置文件有效
缺点:
对于工程学来说,了解生产配置可能被认为是不好的安全实践(一个不好的论点,恕我直言)

拥有网络集中设置存储库

这个对我来说看起来并不吸引人,因为我尝试了三种最终失败的方式:

  1. 在以前的公司,我们在数据库中有配置设置,但当然你不能将它们全部放在那里,因为你需要配置该数据库的连接字符串.此外,在部署之前确保数据库得到适当更新同样困难.
  2. 我们尝试过的另一种方法是使用一种联网服务作为集中式注册表.这几乎可以工作,但是本地缓存总是存在问题,确保配置服务器的URL已正确配置,当然还要配置配置服务器.
  3. 活动目录?EW!需要我多说?

思考?

您使用我正在考虑的选项有多成功?有没有其他替代方案适合您?

byt*_*der 2

我们有一个自定义的 exe,它在我们使用的构建之后运行。

我们的项目有 4 个配置文件

web.config -- 开发(本地框)
web.integration.config -- alpha 测试(在我们的 alpha 服务器上运行)
web.staging.config -- beta 测试(在我们的 beta 服务器上运行)
web.production.config -- 生产(在我们的生产服务器上运行)

该exe只是删除除所需文件之外的所有文件,然后将其重命名为web.config...

我们不允许非开发人员(QA、DBA 等)操作配置文件,因为他们可能会更改为生产值(邮件服务器、sql 服务器)并导致一些严重问题...

它对我们来说非常有效