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

Question

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

我正在开发服务器上开发 Web 应用程序。我在两个地方定义了 Web 应用程序的绝对路径名（而不是文档根目录）。在生产服务器上，此路径有所不同。我很困惑如何处理这个问题。

我可以：

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

我不喜欢#1，因为我宁愿让应用程序保持灵活性以适应未来的任何变化。我不喜欢#2，因为如果我开始在具有第三条路径的第二个开发服务器上进行开发，我就必须在每次提交和更新时更改它。

处理这个问题的最佳方法是什么？我想到：

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

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

3. 从版本控制之外的配置文件中提取路径。然后我必须将配置文件放在所有服务器上的同一位置。或许一开始就走同样的路。

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

Answer 1

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

我觉得构建我的系统很容易并且很容易支持多个配置，并且我经常将配置文件并行提交到源代码控制中，但是生产是混淆的（没有真正的密码），并且开发是模板化的（所以a checkout无法覆盖开发人员的配置）。代码始终以与配置无关的方式打包 - 可以在任何地方部署相同的二进制文件。

不幸的是，大多数语言/开发平台都不支持这一点（与Ruby on Rails不同）。因此，你必须在不同程度上自己构建它。

通常，基本原则是将间接合并到您的配置中：在代码中不指定配置，而是指定如何查找配置。并且通常调用几个间接：特定于用户，特定于应用程序，特定于机器，特定于环境。每个都应该以明确定义的位置/方式找到，并且它们之间应该有一个非常明确的优先级（通常是用户通过机器而非应用程序而不是环境）。您通常会发现每个可配置设置都在一个位置具有自然主页，但不要将该依赖项硬编码到您的应用程序中。

我发现设计应用程序以报告其配置并进行验证非常有价值。在大多数情况下，丢失或无效的配置项应导致中止应用程序。尽可能在启动时执行该验证（并中止）=快速失败。硬编码默认只有在可以可靠使用时才会默认。

摘要配置访问，以便大多数应用程序不知道它来自何处或如何处理。我更喜欢创建 Config 类，将可配置设置暴露为单独的属性（在相关时强类型），然后我“注入”他们通过IOC进入应用程序类。不要让所有应用程序类直接调用所选平台的原始配置框架;抽象是你的朋友。

在大多数企业级（财富500强）组织中，除了该环境的管理团队之外，没有人会看到生产（甚至测试）环境配置。配置文件永远不会在发行版中部署，它们由管理团队手动编辑。相关的配置文件肯定永远不会与代码并排检查到源代码控制中。管理团队可以使用源代码管理，但它是他们自己的私有存储库。 Sarbanes-Oxley和类似法规也倾向于严格禁止开发人员访问（近）生产系统或任何敏感配置数据。在设计方法时要小心。

享受。

Answer 2

您应该始终将历史记录（源代码管理的用途）与部署分开。

部署涉及：

• 一组已识别的数据（SCM 提供的标签或标签会派上用场）
• 操作这些数据的进程（至少将它们复制到正确的位置，而且还扩展一些压缩文件，等等......）

在部署执行的各种操作中，您应该包括 去变量化 阶段。

变量是一个关键字，表示根据您的部署平台（可以是用于持续集成的 PC、用于基本认证的 Linux、用于预生产认证的旧 Solaris8 以及用于生产的带有区域的 Full F15K Solaris10）的任何内容的关键字：它很短，可能会有很大差异）。看 乔纳森·莱弗勒的回答 实际例子。

变量可以表示路径、JVM 版本、一些 JVM 设置等，并且您放入 SCM 中的内容应该是包含变量的数据，而不是硬编码设置。

下一步是在可执行文件中包含一种方法来检测设置文件中的任何更改，以便在运行某些参数时进行更新（避免所有“关闭/更改设置/重新启动”序列）。
这意味着他们是 两种类型的部署变量:

• 静止的 那些（永远不会改变），
• 动态的 （最好在运行时会话期间考虑到这一点）

Answer 3

尽可能避免使用绝对路径。

不要依赖当前的版本控制来做一些神奇的事情 - 您可能会在将来更改版本控制系统。

最简单的方法对我有用：有一个'config.live'并且'config'被配置用于开发。在部署期间，只需将config.live移动到config，一切都很好。对于更复杂的配置，可能需要每个配置的子目录。

一组部署过程至关重要 - 因为配置只是一个不同的区域。

任何更复杂的东西几乎肯定会导致比它解决的更多问题。

Answer 4

使用Git等SCM进行版本控制和部署工具如Capistrano部署。尽管Capistrano最初是为Ruby on Rails创建的，但将它用于其他框架和语言是完全没问题的。

主要的是，特定的部署工具可以让您灵活地自动化两端的路径。

Answer 5

我喜欢Ruby on Rails处理这类问题的方式 - 特定于环境的配置文件。 Rails支持开发，测试和生产数据库连接 - 由database.yml文件中的配置控制。这是一篇关于创建其他特定于环境的配置选项的博客文章，它适用于Rails，但可能会为您提供有关如何为您的环境执行类似操作的一些想法。 http://usablewebapps.com/2008/09 / YAML和 - 定制配置换轨项目/

Answer 6

听起来你的生产代码是完整的git存储库，并且为了更新生产你做了 git pull ？您可能希望尝试单独的构建过程来检查存储库中的代码并创建一个干净的构建（没有.git文件夹）。您可以拥有特定于环境的配置文件，其中包含与其一起复制或创建的路径。