git - 在版本控制下处理系统特定信息的最佳实践是什么？

Question

我是版本控制的新手，所以如果有一个众所周知的解决方案，我深表歉意。特别是对于这个问题，我正在使用 git，但我很好奇如何为所有版本控制系统处理这个问题。

我正在开发服务器上开发网络应用程序。我在两个地方定义了 Web 应用程序(不是文档根目录)的绝对路径名。在生产服务器上，这个路径是不同的。我对如何处理这个感到困惑。

我可以:

1. 重新配置开发服务器以与生产服务器共享相同的路径
2. 每次更新生产时编辑这两个事件。

我不喜欢 #1，因为我宁愿保持应用程序的灵 active 以应对 future 的任何变化。我不喜欢 #2，因为如果我开始使用第三条路径在第二个开发服务器上进行开发，我将不得不为每次提交和更新更改它。

处理此问题的最佳方法是什么？我想到了:

1. 使用自定义关键字和变量扩展(例如在版本控制属性中设置属性 $PATH$ 并使其在所有文件中扩展)。 Git 不支持这一点，因为这会对性能造成巨大影响。

2. 使用更新后和提交前 Hook 。可能是 git 的可能解决方案，但每次我查看状态时，它都会报告这两个文件已更改。不是很干净。

3. 从版本控制之外的配置文件中提取路径。然后我必须将配置文件放在所有服务器上的相同位置。还不如从相同的路径开始。

有没有简单的方法来处理这个问题？我是不是想多了？

Answer 1

永远不要对文件系统路径等配置数据进行硬编码，并强制多个部署进行匹配。那是黑暗的一面，那里有很多苦难。

我发现构建我的系统以轻松支持多种配置既有用又容易，而且我经常将配置文件并排提交到源代码管理中，但生产的是混淆的(没有真正的密码)，开发的是模板化的(所以 checkout 不能覆盖开发人员的配置)。代码始终以与配置无关的方式打包——相同的二进制文件可以部署在任何地方。

不幸的是，大多数语言/开发平台并不支持这一点(不像 Ruby on Rails)。因此，您必须在不同程度上自己构建它。

一般来说，基本原则是将间接 merge 到您的配置中:在您的代码中指定的不是配置，而是如何找到配置。并且通常会调用几个间接寻址:特定于用户的、特定于应用程序的、特定于机器的、特定于环境的。每个都应该以明确定义的位置/方式找到，并且它们之间应该有明确定义的优先级(通常是用户优先于机器优先于应用优先于环境)。您通常会发现每个可配置的设置在一个位置都有一个自然的家，但不要将这种依赖性硬编码到您的应用程序中。

我发现将应用程序设计为能够报告其配置并对其进行验证是非常有值(value)的。在大多数情况下，丢失或无效的配置项会导致应用程序中止。尽可能在启动时执行验证(并中止)= 快速失败。仅当可以可靠地使用时才采用硬编码默认值。

抽象配置访问，以便大多数应用程序不知道它来自何处或如何处理。我更喜欢创建 Config 类，将可配置设置公开为单独的属性(相关时为强类型)，然后通过 IOC 将它们“注入(inject)”到应用程序类中。不要让所有应用程序类直接调用所选平台的原始配置框架；抽象是你的 friend 。

在大多数企业级(财富 500 强)组织中，除了该环境的管理团队之外，没有人看到生产(甚至测试)环境配置。配置文件永远不会部署在一个版本中，它们是由管理团队手工编辑的。相关的配置文件肯定永远不会与代码一起 checkin 源代码管理。管理团队可能会使用源代码控制，但这是他们自己的私有(private)存储库。 Sarbanes-Oxley 和类似法规也倾向于严格禁止开发人员对(接近)生产系统或任何敏感配置数据进行一般访问。在设计方法时请注意。

享受吧。