处理多个部署的配置

Question

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

我们目前有自定义的Xml文件，这些文件是根据机器名称和配置的客户加载的，所以如果机器被称为machine-01，它会进入名为machine-01的文件夹，如果客户名称是customer-01，它会尝试在customer-01.config中查找该文件夹中的文件。这对我们来说效果很好，因为每台开发机器都有自己的配置文件，我们可以为客户创建配置文件并将其保存在TFS中。

这个问题有两个方面：

1. 我们手动复制配置文件而不是自动部署。
2. 生产凭据在TFS中，可供任何开发人员使用，但如果将错误的设置复制到自己的文件中，他们可能无法运行生产凭据。

我们已经开始查看配置转换，但我们没有使用web.config / app.config，因为我们从自定义Xml文件加载这些转换。我们可以在visual studio中的自定义Xml文件上进行配置转换吗？

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

虽然我们目前只有四个单独的部署，但是更多的客户似乎想要在他们自己的基础架构上托管，因为产品与他们的系统集成了很多定制的可插拔项目。

我的问题是人们如何处理这些类型的部署，其中存在多个配置文件，特别是从尝试隐藏来自TFS /其他开发人员的生产凭证以减轻开发中使用的生产凭证的风险的角度，而且从角度来看自动部署到azure和自托管窗口。

我的研究提出了2006/2008年的文章，我不得不相信现在有更好的方法。我们也在使用Visual Studio Online进行TFS。

Answer 1

过去我使用XmlPreprocess成功了。我们的想法是标记您的配置文件，以便对它们进行处理，并将值替换为来自Excel文件等源的宏。您还拥有源并根据您的特定需求调整工具。

Answer 2

我期待Visual Studio的Release Management。它旨在实现您所谈论的内容并保持权威的可追溯性。您可以在多个环境中创建发布管道，并自动处理每个环境的所有变量。

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

Answer 3

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

请参阅：https://contemplate.codeplex.com/

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