Deployment 跨环境管理配置文件

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

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

我不知道这是一个大系统，还是一个小系统，但我的意见是，在我们不同的环境（测试、验收和生产环境）中启动和运行系统需要花费太长的时间

在我们的VisualStudio项目中，每个环境都有配置文件。因此，一个用于开发的

web.test.config

、一个

web.acc.config

、一个

web.prod.config

和一个

web.config

。它们都有相同的键，但值可能不同，这取决于它们所处的环境

如果我在webapp的web.config中快速计算appsettings，我会计算32。我数了5个端点。我们有四个环境（dev、test、acc和prod），这意味着一个web应用总共有128个appsettings和20个端点。我们很容易犯错误，尤其是在截止日期临近的时候

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

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

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

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

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

---

因此，我的问题是：您如何管理配置、基础架构及其相关流程？

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

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

您可能能够修改该概念，以使用您在基于.Net/WCF的项目中使用的任何配置语法（我不熟悉这些技术，但我猜它们可能使用基于XML的配置文件）。特别是，您可以使用Python编写一个脚本，该脚本使用if-then-else语句在

map

中设置特定于环境的名称=值对，然后使用一些

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.
#--------
...

---

为了获得额外的分数，脚本还可以生成需要为环境执行的测试清单，例如，“检查是否需要在以下端点之间打开防火墙端口：…”

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

所以我只依赖数据库团队来更新设置（若你们可以直接访问数据库，那个就更容易了），而且我并没有风险在我的开发PC上运行一个指向prod数据库的代码：D

---

但是我没有Visual Studio的经验，所以我不确定您是否可以在您的案例中应用类似的东西，但我希望它能给您一些想法。

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

• 关于您的特殊情况，其中一个文件中的更改可能在其他文件中被遗忘，等等：我想这将很容易用测试脚本自动检查

• 未提交的更改应该像“git diff master”或您使用的任何vcs一样易于检测

• 了解哪些端口需要为服务开放似乎更像是一个适当的文档问题，而不是配置管理问题

---

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

听起来您有一个足够小的环境，可以轻松管理所有配置文件