如何实现.NET部署涅盘？

我们的公司已经接近“上线”日期（以及获得QA部门的日期），我正试图定义正确的操作流程来支持这一点。我要考虑的一个重要问题是如何避免不可避免地出现部署/配置地狱。你们中有没有人找到了一个好的解决方案，可以将构建交给非程序员，这样他们就可以在QA、登台和生产环境中成功地安装和配置它

我们的完整环境由异构计划任务、Windows服务和网站组成，所有这些都可以通过并行部署进行扩展。谢天谢地，配置方法是一致的。不幸的是，所有这些都是通过.NET web/app.config文件管理的。根据我的经验，QA和ops人员在试图修改它们时总是搞砸（XML对于大多数人来说是出人意料的难以处理！）

以下是我正在考虑的选项：

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

赞成的意见： 这可能会减少部署系统所需的步骤数量 欺骗： 必须以某种方式记录配置架构更改 未知数： 我们使用自定义配置节和引用程序集的其他配置扩展。这是否需要我们在计算机的GAC中安装.NET程序集？ 在生成过程中执行配置文件操作 如果我们设置QA、登台和生产环境，使它们看起来与我们的软件（虚拟服务器和LAN等）相同，QA应该能够在不更改配置的情况下将就绪软件直接转换到登台环境，并将登台转换到生产环境。通过这种设置，理论上我们可以将QA预配置的foo.config文件交给任何人都不需要触摸的人

赞成的意见： 工程部门将更善于确保配置文件有效 欺骗： 对于工程人员来说，了解生产配置可能被认为是糟糕的安全实践（一个糟糕的论点，IMHO） 拥有一个网络集中设置存储库 这一条对我来说没有吸引力，因为我尝试了三种方法，但最终都失败了：

在以前的一家公司，我们在数据库中有配置设置，但当然不能将它们全部放在那里，因为您需要配置到该数据库的连接字符串。此外，在部署之前确保数据库得到正确更新也同样困难

我们尝试过的另一种方法是使用一种网络服务，它可以作为一种集中的注册表。这几乎起到了作用，但本地缓存总是存在问题，确保配置服务器的URL配置正确，当然还包括配置服务器

活动目录？电子战！我还需要多说吗

思想？

---

您使用我正在考虑的选项有多成功？除了这些，还有什么其他方法对您很有效吗？

我见过一些公司使用部署脚本和虚拟机来镜像生产，以便在按下按钮时部署QA构建和暂存构建。您可以使用Powershell执行此操作。

我想说的是，您可以执行以下几项操作：

首先，使用临时服务器。无论是工程还是非工程，都要有一个位置，在那里您可以对服务器执行代码的“模拟部署”，并从那里测试代码。这有助于提供一个独特的“类似生产”的环境进行测试，并允许进行部署培训，而不会导致每个人都因为害怕在部署中使用核武器而变得异常和不稳定。就硬件而言，它的成本稍高一些，但从它所防止的错误来看，它可能是值得的

---

第二，如果您的配置文件非常复杂，并且非工程师很难构建它们，请创建一个快速工具来创建用于部署的验证文件。一个简单的网站，甚至客户端应用程序，只要获取基本的部署参数，对其进行一些验证，然后以正确的格式保存所有内容，就可以在帮助一些技术含量较低的人方面创造奇迹。拥有一个验证输入的工具对这些类型的人来说确实很有用，并且知道您将始终拥有格式良好、结果经过验证的XML，这也可以节省一些工程师担心的时间。

我一直成功地将本地和数据库驱动的存储设置混合在一起。特定于机器的设置存储在机器上的XML文件中（包括根数据库的连接信息），任何特定于应用程序（但不是特定于用户）的设置也是如此。任何特定于用户或企业范围的设置都存储在数据库中，包括其他数据库的连接信息。换句话说，我们有一个包含这些信息的数据库，客户端可以使用它连接到其他数据库。这使我们能够集中维护除与根数据库的连接之外的所有内容。

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

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

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

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

我们不允许非开发人员（QA、DBA等）操纵配置文件，因为它们可能会更改为生产val