Deployment 处理多个部署的配置

我们仍在努力确定最佳的前进方向，目前我们有一个asp.net MVC网站，在我们管理的专用服务器上部署了windows服务，在他们管理的一些客户基础设施上也部署了windows服务。我们正在将应用程序迁移到Azure，尽管它仍然需要支持标准windows部署。我们已经处理了这个问题，但问题是配置文件

我们目前有基于机器名和配置的客户加载的自定义Xml文件，因此，如果机器名为machine-01，它将转到名为machine-01的文件夹，如果客户名为customer-01，它将尝试在该文件夹中查找customer-01.config的文件。这对我们来说非常有效，因为每台开发机器都有自己的配置文件，我们可以为客户创建一个配置文件并将其保存在TFS中

这有两个问题：

我们正在手动复制配置文件，而不是进行自动部署

生产凭据位于TFS中，可供任何开发人员使用，但如果他们将错误设置复制到自己的文件中，则不太可能运行生产凭据

我们已经开始研究配置转换，但我们没有使用web.config/app.config，因为我们是从自定义Xml文件加载这些转换的。我们可以在VisualStudio中对自定义Xml文件进行配置转换吗

此外，我不确定我是否满意此解决方案，因为它仍然使TFS中的生产凭据对所有人都可用，并且仍然存在以错误配置编译并在本地运行的风险

虽然目前我们只有四个独立的部署，但更多的客户似乎希望在他们自己的基础设施上进行托管，因为该产品在很大程度上与他们的系统集成，并带有定制的可插拔项目

我的问题是，在存在多个配置文件的情况下，人们如何处理这些类型的部署，特别是从试图向TFS/其他开发人员隐藏生产凭据以降低开发中使用生产凭据的风险的角度，以及从自动化部署到azure和自托管窗口

---

我的研究是2006/2008年的文章，我必须相信现在有更好的方法。我们也在为TFS使用Visual Studio Online。

在过去，我成功地使用了它。其思想是标记配置文件，以便对其进行处理，并用来自Excel文件等源的值替换宏。您还拥有源代码，并根据您的具体需要调整该工具。

我希望Visual Studio的发布管理。它的目的是做你所说的，并保持权威的可追溯性。您可以通过多个环境创建发布管道，并自动处理每个环境的所有变量

---

使用此模型，您可以为具有本地值的开发人员提供一个Web.config，为具有可替换变量的RM提供一个Web.config。然后在部署时处理所有问题。

我最近创建了一个开源项目，该项目处理每个环境中基于模板的配置文件

见：

您可以在一个解决方案中有多个配置文件，将设置保存在每个环境的一个文件中，并在需要时生成配置文件