在版本控制下处理系统特定信息的最佳做法是什么？ [英] What's the best practice for handling system-specific information under version control?

问题描述

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

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

我可以：

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

我不喜欢＃1，因为我宁愿将应用程序保持为任何未来更改的灵活性。我不喜欢＃2，因为如果我开始在第三个路径的第二个开发服务器上开发，那么每次提交和更新都必须更改。

什么处理这个问题的最好方法是什么？我想到：使用自定义关键字和变量扩展（例如在版本控制属性中设置属性$ PATH $和将它扩展到所有文件中）。 Git不支持这个功能，因为它会带来巨大的性能提升。 使用post-update和pre-commit钩子。可能是git的可能解决方案，但每次查看状态时，都会报告这两个文件正在更改。不是很干净。 从版本控制外的配置文件中拉出路径。然后，我将不得不在所有服务器上的相同位置配置文件。可能还有同样的道路开始。

有没有简单的方法来处理这个问题？我是否想过它？

解决方案

不要像文件系统路径那样硬编码配置数据，并强制多个部署匹配。这是一个黑暗的方面，在那里有很多的嗜好。

我觉得构建我的系统很容易，可以轻松地支持多种配置，而且我经常将配置文件提交到源代码控制，但生产的模糊（没有真正的密码）和发展的模板（所以结帐不能覆盖开发人员的配置）。代码总是以与配置无关的方式打包 - 相同的二进制文件可以在任何地方部署。

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

通常，基本原则是将间接引入您的配置：不指定配置，但指定在您的代码中找到配置。通常会调用几个indirections：用户特定的，特定于应用程序的，特定于计算机的，特定于环境的。每个应该以一个明确定义的地方/方式被找到，并且它们之间应该有非常明确的优先级（通常是用户在机器上而不是在环境上的应用）。您通常会发现，每个可配置的设置在一个位置都有一个自然的家，但不要将该依赖关系硬编码到您的应用程序中。

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

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

在大多数企业级（财富500强）组织中，没有人看到除该管理团队外的产品（甚至是测试）环境配置。配置文件从未部署在发行版中，它们由管理团队手动编辑。相关的配置文件当然永远不会与代码并行检入源代码控制。管理团队可能使用源代码管理，但它是他们自己的私有存储库。 萨班斯 - 奥克斯利法案和类似的法规也倾向于严格禁止开发者普遍访问（接近）生产系统或任何敏感的配置数据。当你设计你的方法时请注意。

享受。

I'm new to version control, so I apologize if there is a well-known solution to this. For this problem in particular, I'm using git, but I'm curious about how to deal with this for all version control systems.

I'm developing a web application on a development server. I have defined the absolute path name to the web application (not the document root) in two places. On the production server, this path is different. I'm confused about how to deal with this.

I could either:

1. Reconfigure the development server to share the same path as the production
2. Edit the two occurrences each time production is updated.

I don't like #1 because I'd rather keep the application flexible for any future changes. I don't like #2 because if I start developing on a second development server with a third path, I would have to change this for every commit and update.

What is the best way to handle this? I thought of:

1. Using custom keywords and variable expansion (such as setting the property $PATH$ in the version control properties and having it expanded in all the files). Git doesn't support this because it would be a huge performance hit.

2. Using post-update and pre-commit hooks. Possibly the likely solution for git, but every time I looked at the status, it would report the two files as being changed. Not really clean.

3. Pulling the path from a config file outside of version control. Then I would have to have the config file in the same location on all servers. Might as well just have the same path to begin with.

Is there an easy way to deal with this? Am I over thinking it?

解决方案

Do not EVER hard-code configuration data like file system paths and force multiple deployments to match. That is the dark side, where there is much SUFFERING.

I find it useful and easy to build my systems to support multiple configurations easily, and I routinely commit configuration files into source control side-by-side, but production's is obfuscated (no real passwords) and development's is templated (so a checkout can't overwrite a developer's configuration). The code is always packaged in a configuration-neutral manner--the same binary can be deployed anywhere.

Unfortunately, most language/development platforms do not readily support this (unlike Ruby on Rails). Therefore, you have to build it yourself, to varying degrees.

In general, the basic principle is to incorporate indirection into your configuration: specify not the configuration, but how to find the configuration, in your code. And generally invoke several indirections: user-specific, application-specific, machine-specific, environment-specific. Each should be found in a well-defined place/manner, and there should be a very-well-defined precedence among them (usually user over machine over application over environment). You will generally find that every configurable setting has a natural home in one location, but don't hard-code that dependency into your applications.

I find that it is VERY valuable to design applications to be able to report their configuration, and to verify it. In most cases, a missing or invalid configuration item should result in aborting the application. As much as possible, perform that verification (and abort) at startup = fail fast. Hard-code defaults only when they can reliably be used.

Abstract the configuration access so that most of the application has no idea where it comes from or how it is processed. I prefer to create Config classes that expose configurable settings as individual properties (strongly typed when relevant), then I "inject" them into application classes via IOC. Do not make all your application classes directly invoke the raw configuration framework of your chosen platform; abstraction is your friend.

In most enterprise-class (Fortune 500) organizations, no one sees the production (or even test) environment configurations except the admin team for that environment. Configuration files are never deployed in a release, they are hand-edited by the admin team. The relevant configuration files certainly never get checked into source control side-by-side with the code. The admin team may use source control, but it is their own private repository. Sarbanes-Oxley and similar regulations also tend to strictly forbid developers from having general access to (near-)production systems or any sensitive configuration data. Be mindful as you design your approach.

Enjoy.

这篇关于在版本控制下处理系统特定信息的最佳做法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！