Question

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

我在一家公司工作，我们与大约15名开发人员一起开发软件。我们构建了部署在托管主机提供商处的业务线网络应用程序。我们的主要应用程序之一包括一个网站和大约十个WCF服务。有些服务相互连接。

我不知道这是一个大系统，还是小系统，但我认为这需要我们太长时间才能在不同的环境（测试，验收和生产）中进行操作。

我们的Visual Studio项目中的每个环境都有配置文件。因此，web.test.config，web.acc.config，web.prod.config和web.config用于开发。它们都有相同的键，但值可能不同，具体取决于它们的环境。

如果我快速计算webapp的web应用程序中的appsettings，我算上32个。我算了5个端点。我们有四个环境（dev，test，acc和prod），这意味着一个Web应用程序共有128个appsettings和20个端点。我们很容易犯错误，特别是在截止日期结束时。

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

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

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

我们在Test中执行此操作，但在Acceptance中我们必须再次执行此操作，并且我们忘记了必须打开哪些端口，因此更像是试错：哦我的服务无法连接到数据库，可能是港口关闭了。生产中也可能出现同样的问题。

根据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

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

关于您的特殊情况，其中一个文件中的更改可能已被其他文件遗忘等等：我想这可以很容易地通过测试脚本进行自动检查。
未提交的更改应该像“git diff master”或您使用的任何vcs一样容易检测。
要知道哪些端口需要为服务打开，这似乎更像是一个正确的文档问题，而不是配置管理。

许多使用我们系统的网站也使用puppet来管理不同节点的配置。我不确定这是否适合你，但值得一看。

Answer 3

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

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

Answer 4

听起来您的环境足够小，您可以使用Ansible templates或SaltStack轻松管理所有配置文件。

Answer 5

在http://www.configapp.com处查看Config。它的工作方式是导入一个名为web.config的基本配置文件。然后从webapp中，您将创建4个环境，dev，test，acc和prod。转到dev环境，创建环境变量，并设置适合环境的值。您将只使用环境变量维护一个配置文件。您可以查看所有环境变量，并轻松查看环境之间的差异。

您将减少错误，因为您只需要管理一个配置文件。当您添加新的公共/静态配置时，所有环境都会神奇地拥有该新设置。添加变量配置时，只需转到正确的环境选项卡并在其中设置值。您可以查看所有环境的特定配置值，因此可以快速检查是否遗漏了某些内容。您还可以按照每个环境对每个配置文件进行观察，因为它们就在您面前。您不需要RDP / SSH到每个服务器。

您将不会忘记签入，因为Config将成为主副本，您不会再直接编辑配置文件。如果您直接编辑它们，我们有一个diff功能，因此您可以看到主副本和本地副本之间的差异。您可以使用适合您团队的各种部署模型将主副本部署到本地服务器。您可以按，手动拉，自动拉或导出/复制。

我们将支持自定义类型，我们将来可以添加的一件事是端口数据类型。端口验证的一部分是检查端口是否打开。这只能使用内部部署计划，因为它需要访问内部网络。或者你可以手动检查它。转到端口环境变量，并显示当前配置的所有端口。检查列表中的每个端口。如果端口看起来不错，请在Config中添加一条注释，表明它已打开并在特定日期进行了检查。 Config专为搜索和文档而设计。

顺便说一下，我是Config团队的一员。

Answer 6

就个人而言，如果有可能，我会通过以下方式进行管理：所有“静态”环境设置（数据库连接，LDAP等）都放在服务器配置文件中（不受代码迁移影响），并且“动态” “数据库本身的设置。

所以我只依靠数据库团队来更新设置（如果你有权直接访问数据库，那就更容易了）。我没有风险在我的开发PC上运行指向prod数据库的代码：D

但我没有Visual Studio经验，所以我不确定你是否可以在你的情况下应用类似的东西，但我希望它可以给你一些想法。

Answer 7

您是否考虑过使用部署管理工具来处理它？我曾在运营团队中部署过一个产品，该产品具有大约10个需要相互交谈的不同系统，因此我非常了解您的情况。部署整个解决方案大约需要4个小时的手动步骤+ 2个小时的测试。我们决定使用Octopus Deploy（https://octopus.com）来自动化部署过程。该工具可以在配置文件中进行变量替换，您可以定义每个环境的变量（还有更多...）现在整个解决方案的部署大约需要15分钟，最终结果总会很好...您还可以触发发布直接从TFS，VSTS，Jenkins或TeamCity创建和部署，这样您就可以拥有非常可靠的CI / CD方法。

希望这会有所帮助。

跨环境管理配置文件

7 个答案: