跨环境管理配置文件

Question

您(您的公司)如何管理您构建的应用程序/系统的配置文件？让我告诉你我们是如何做到的，以及问题是什么。

我在一家公司工作，我们和大约15名开发人员一起开发软件。我们构建业务线web应用程序，部署在我们的托管主机提供商。我们的一个主要应用程序由一个网站和大约十个WCF服务组成。其中一些服务是相互连接的。

我不知道这是一个大系统还是小系统，但我的观点是，在我们不同的环境(测试、验收和生产)中，我们需要花费太长的时间才能启动和运行。

在我们的Visual Studio项目中，我们有每个环境的配置文件。所以一个web.test.config，一个web.acc.config，一个web.prod.config和一个web.config用于开发。它们都有相同的键，但值可以不同，这取决于它们所针对的环境。

如果我对webapp的web.config中的应用程序设置进行快速计数，我会发现有32个。我数到了5个端点。我们有四个环境(dev、test、acc和prod)，这意味着一个web应用总共有128个应用程序设置和20个端点。我们很容易犯错误，特别是在最后期限临近的时候。

我们都是人，所以这样的事情可能发生在任何人身上：

• 我们对其中一个配置文件进行了更改，但在构建和部署之前忘记了签入。
• ，或者我们在WebServer上进行更改，而忘记在其他四个web.configs中进行相应的更新。
• ，或者我们只更改四个配置文件中的三个。以此类推。

然后我们就有了托管主机提供商的基础设施。默认情况下，每个端口都处于关闭状态。因此，如果其中一个WCF服务需要与位于不同服务器上的另一个WCF服务进行通信，则必须打开一个受防火墙保护的端口。

我们在Test中这样做，但在验收时，我们不得不再次这样做，并且我们忘记了必须打开哪些端口，所以这更像是反复试验:哦，我的服务无法连接到数据库，可能是端口关闭了。同样的问题也可能发生在生产中。

根据SLA，我们的托管主机提供商可能需要几天时间才能打开防火墙中的端口。因此，这很快就变成了一个相当漫长的过程。最后，我们需要大约两个月的时间才能完成测试、验收和生产并投入运行。

因此，我的问题是:您如何管理配置和基础设施以及围绕它的流程？

Answer 1

Config4*项目(免责声明:我是它的主要开发人员)没有与.Net或WCF的开箱即用的集成，因此它可能对您没有用处。但是，Config4*中的一项功能与您的问题相关:它能够在配置文件中嵌入if-then-else语句，以便该文件能够针对不同的环境(例如开发、测试、验收和生产)“自适应”。

您可以修改该概念以使用您在基于.Net/WCF的项目中使用的任何配置语法(我不熟悉这些技术，但我猜它们可能使用基于XML的配置文件)。具体地说，您可以使用Python编写脚本，该脚本使用if- then -else语句在map中设置特定于环境的name=value对，然后使用一些print语句生成一组为环境量身定做的配置文件。这样的脚本的伪代码大纲是：

#--------
# Set up configuration variables suitable for a specified environment
#--------
cfg["variable1"] = "default value";
cfg["variable2"] = "another default value";
if (environment == "testing") {
  cfg["variable1"] = "override default value for this environment";
  cfg["variable3"] = "value suitable for this environment";
  ...
} else if (environment == "production") {
  ...
}
#--------
# Now use print statements to generate configuration files
# Alternatively, use the _name=value_ pairs in the map to
# perform global search-and-replace on template versions of
# configuration files.
#--------
...

对于加分，脚本还可以生成需要为环境执行的测试的检查表，例如，“检查是否需要在以下端点之间打开防火墙端口：...”

Answer 2

这可能会有所帮助，它讨论了配置文件的中央位置和从一个源引用的服务。

http://blogs.msdn.com/b/youssefm/archive/2010/09/02/loading-wcf-client-configuration-from-different-files-with-configurationchannelfactory.aspx

Answer 3

我们正在开发一个分布式存储系统，我们在单元和集成测试中发现了许多类似的问题，这些测试在每次构建时都会运行。此外，我们正在使用ReviewBoard，以便其他开发人员在提交之前查看任何更改。下一步是在不同环境中自动部署和测试工件的持续集成服务器(jenkins)。最后，我们的最后一道防线是我们的压力测试平台，它可以在发布之前针对任何新版本运行。当然，尽可能好地模拟您的生产环境是必不可少的，但如果您总是在同一托管提供商处部署，这应该不会太难。

• 关于您的特殊情况，其中一个文件中的更改可能在其他文件中被遗忘，等等:我认为这将很容易通过测试自动检查script.
• Uncommitted更改应该像"git diff master“一样容易检测，或者您使用的任何vcs。
• 要知道需要为服务打开哪些端口似乎更像是一个适当的文档问题，而不是配置管理的问题。

许多使用我们系统的站点也使用puppet来管理其不同节点的配置。我不确定这是否是你的一个选择，但它可能值得一看。