我是版本控制的新手,所以如果有一个众所周知的解决方案我会道歉.特别是对于这个问题,我正在使用git,但我很好奇如何处理所有版本控制系统.
我正在开发服务器上开发Web应用程序.我已经在两个地方定义了Web应用程序的绝对路径名(而不是文档根目录).在生产服务器上,此路径不同.我对如何处理这件事很困惑.
我可以:
重新配置开发服务器以共享与生产相同的路径
每次更新生产时编辑两次出现.
我不喜欢#1,因为我宁愿让应用程序灵活应对未来的任何变化.我不喜欢#2,因为如果我开始使用第三个路径开发第二个开发服务器,我将不得不为每次提交和更新更改它.
处理这个问题的最佳方法是什么？我想到了:
使用自定义关键字和变量扩展(例如在版本控制属性中设置属性$ PATH $并在所有文件中展开它).Git不支持这一点,因为它会带来巨大的性能损失.
使用更新后和预提交挂钩.可能是git的可能解决方案,但每次我查看状态时,它都会报告这两个文件被更改.不太干净.
从版本控制之外的配置文件中提取路径.然后我必须将配置文件放在所有服务器上的相同位置.也可能只有相同的路径开始.
有一个简单的方法来处理这个？我在想它吗？
不要对文件系统路径等配置数据进行硬编码,并强制要求多个部署匹配.那是黑暗的一面,那里有很多的苦难.
我发现构建我的系统很容易并且很容易支持多个配置,并且我经常将配置文件并行提交到源代码控制中,但是生产是混淆的(没有真正的密码),并且开发是模板化的(所以结账可以' t覆盖开发人员的配置).代码总是以与配置无关的方式打包 - 可以在任何地方部署相同的二进制文件.
不幸的是,大多数语言/开发平台都不支持这一点(与Ruby on Rails不同).因此,你必须在不同程度上自己构建它.
通常,基本原则是将间接合并到您的配置中:在代码中指定不是配置,而是如何查找配置.并且通常调用几个间接:特定于用户,特定于应用程序,特定于机器,特定于环境.每个都应该以明确定义的位置/方式找到,并且它们之间应该有一个非常明确的优先级(通常是用户通过机器而非应用程序而不是环境).您通常会发现每个可配置设置都在一个位置具有自然主页,但不要将该依赖项硬编码到您的应用程序中.
我发现设计应用程序以报告其配置并进行验证非常有价值.在大多数情况下,丢失或无效的配置项应导致中止应用程序.尽可能在启动时执行该验证(并中止)=快速失败.硬编码默认仅在可以可靠使用时才会默认.
摘要配置访问,以便大多数应用程序不知道它来自何处或如何处理.我更喜欢创建Config将可配置设置作为单独属性公开的类(在相关时强类型化),然后通过IOC将它们"注入"到应用程序类中.不要让所有应用程序类直接调用所选平台的原始配置框架; 抽象是你的朋友.
在大多数企业级(财富500强)组织中,除了该环境的管理团队之外,没有人会看到生产(甚至测试)环境配置.配置文件永远不会在发行版中部署,它们由管理团队手动编辑.相关的配置文件肯定永远不会与代码并排检查到源代码控制中.管理团队可以使用源代码管理,但它是他们自己的私有存储库.Sarbanes-Oxley和类似法规也倾向于严格禁止开发人员访问(近)生产系统或任何敏感配置数据.在设计方法时要小心.
请享用.
京公网安备 11010802040832号 | 京ICP备19059560号-6 