您(您的公司)如何管理您构建的应用程序/系统的配置文件？让我告诉你我们是如何做到的，以及问题是什么。
我在一家公司工作，我们与大约 15 名开发人员一起开发软件。我们构建在托管托管提供商处部署的业务线 Web 应用。 我们的主要应用程序之一包括一个网站和大约十个WCF服务。某些服务相互连接。
我不知道这是一个大系统还是小系统，但我的观点是，我们在不同的环境(测试、验收和生产)中启动和运行需要很长时间。
我们在Visual Studio项目中为每个环境都有配置文件。因此，一个web.test.config，一个web.acc.config，一个web.prod.config，一个发展web.config。它们都具有相同的键，但值可能不同，具体取决于它们所适用的环境。
如果我在 web.config 中对 webapp 的应用程序设置进行快速计数，我会数到 32。我数了 5 个端点。我们有四个环境(开发、测试、acc 和 prod)，这意味着一个 Web 应用总共有 128 个应用设置和 20 个端点。我们很容易犯错误，尤其是在截止日期临近的时候。
我们都是人类，所以这样的事情可能发生在任何人身上：
- 我们在其中一个配置文件中进行了更改，但在构建和部署之前忘记签入。
- 或者我们在 Web 服务器上进行了更改，而忘记在其他四个 web.config 中进行相应的更新。
- 或者我们只更改四个配置文件中的三个。等等。
然后，我们在托管托管服务提供商处拥有基础架构。默认情况下，每个端口都处于关闭状态。因此，如果其中一个 WCF 服务需要与位于其他服务器上的另一个 WCF 服务通信，则必须打开受防火墙保护的端口。
我们在测试中这样做，但在验收中我们必须再做一次，我们已经忘记了必须打开哪些端口，所以这更像是试错：哦，我的服务无法连接到数据库，可能是端口已关闭。同样的问题也可能发生在生产中。
根据 SLA，我们的托管托管服务提供商可能需要几天时间才能在防火墙中打开端口。因此，这很快就会成为一个相当漫长的过程。最后，我们花了大约两个月的时间才能启动并运行测试、验收和生产。
所以，我的问题是：您如何管理配置、基础架构和围绕它的流程？
Config4* 项目(免责声明：我是其主要开发人员)没有与 .Net 或 WCF 的开箱即用集成，因此它可能对您没有用。但是，Config4* 中的一个功能与您的问题相关：它能够在配置文件中嵌入 if-then-else 语句，以便文件可以"适应"不同的环境(例如开发、测试、验收和生产)。
您可以修改该概念以使用您在基于 .Net/WCF 的项目中使用的任何配置语法(我不熟悉这些技术，但我猜它们可能使用基于 XML 的配置文件)。特别是，你可以使用Python编写一个脚本，该脚本使用if-then-else语句在map中设置特定于环境的name=值对，然后使用一些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.
#--------
...
对于奖励积分，该脚本还可以生成需要为环境执行的测试清单，例如，"检查是否需要在以下端点之间打开防火墙端口：...">
这可能会有所帮助，它讨论了从一个源引用的配置文件和服务的中心位置。
http://blogs.msdn.com/b/youssefm/archive/2010/09/02/loading-wcf-client-configuration-from-different-files-with-configurationchannelfactory.aspx
听起来你有一个足够小的环境，你可以使用Ansible模板或SaltStack轻松管理所有配置文件。
我们正在开发一个分布式存储系统，我们在每次构建时运行的单元和集成测试中都发现了许多这样的问题。此外，我们正在使用ReviewBoard，让其他开发人员在提交之前查看任何更改。下一步是持续集成服务器 (Jenkins)，它在不同的环境中自动部署和测试工件。最后，我们的最后一道防线是我们的压力测试平台，它可以在任何新版本发布之前针对任何新版本运行。 当然，拥有一个尽可能好地模拟生产环境的测试平台是必不可少的，但是如果您总是在同一托管提供商处部署，那应该不会太难。
-
关于您的特殊情况，一个文件中的更改可能已被其他文件遗忘，等等：我想使用测试脚本自动检查这很容易。
-
未提交的更改应该像"git diff master"或您使用的任何 vcs 一样容易检测。
-
要知道需要为服务打开哪些端口，似乎更像是一个适当的文档问题，而不是配置管理的问题。
许多使用我们系统的站点也使用 puppet 来管理其不同节点的配置。我不确定这是否适合您，但可能值得一看。
看看 Config at http://www.configapp.com。它的工作方式是您将导入一个名为web.config的基本配置文件。然后，您将在 Web 应用程序中创建 4 个环境：开发、测试、acc 和 prod。转到开发环境，创建环境变量，并设置适合环境的值。您将只维护一个包含环境变量的配置文件。您可以查看所有环境变量，并轻松查看环境之间的差异。
您将犯更少的错误，因为您只有 1 个配置文件要管理。添加新的通用/静态配置时，所有环境都将神奇地具有该新设置。添加变量配置时，只需转到正确的环境选项卡并在那里设置值即可。您可以查看所有环境的特定配置值，以便快速检查是否遗漏了某些内容。您还可以查看每个环境的每个配置文件，因为它们就在您面前。不需要通过 RDP/SSH 连接到每个服务器。
您不会忘记签入，因为 Config 将是主副本，并且您不会再直接编辑配置文件。如果您直接编辑它们，我们有一个差异功能，因此您可以看到主副本和本地副本之间的差异。您可以使用适合您团队的各种部署模型将主副本部署到本地服务器。您可以推送、手动拉取、自动拉取或导出/复制。
我们将支持自定义类型，将来我们可以添加的一件事是端口数据类型。端口验证的一部分是检查端口是否打开。这仅适用于本地计划，因为它需要访问内部网络。或者您可以手动检查它。转到端口环境变量，并显示当前配置的所有端口。检查列表中的每个端口。如果端口看起来不错，请在 Config 中添加一条注释，说明它已打开并且在特定日期被选中。配置专为搜索和文档而设计。
顺便说一下，我是配置团队的一员。
就个人而言，如果可能的话，我会通过以下方式管理它：所有"静态"环境设置(数据库连接、LDAP 等)都放在服务器配置文件中(不受代码迁移的影响)，"动态"设置放在数据库本身中。
所以我只依靠数据库团队来更新设置(如果您可以直接访问数据库，那就更容易了)。而且我没有风险在我的开发PC上运行指向生产数据库:D的代码
但是我没有Visual Studio的经验，所以我不确定你可以在你的案例中应用类似的东西，但我希望它能给你一些想法。
您是否考虑过使用部署管理工具来处理它？ 我曾在运营团队中工作，负责部署一个产品，该产品有大约 10 个需要相互通信的不同系统，所以我真的很了解您的情况。 部署整个解决方案大约需要 4 小时的手动步骤 + 2 小时的测试。 我们决定使用八达通部署(https://octopus.com)来自动化部署过程。 此工具可以在配置文件中进行变量替换，您可以为每个环境定义变量(以及更多... 整个解决方案的部署现在大约需要 15 分钟，最终结果总是好的...... 您还可以直接从 TFS、VSTS、Jenkins 或 TeamCity 触发发布创建和部署，以便您可以拥有非常可靠的 CI/CD 方法。
希望这有帮助。