如何在我的产品中在Git级别具有多个模块的情况下处理硬编码的URL和数据库配置? [英] How do I handle hard coded URL, database configuration in my product that has multiple modules in Git level?

问题描述

我正在研究多年来由多个开发人员开发的产品.

I am working on a product that has been developed by multiple developers over the years.

该产品基于

• PHP
• jQuery
• 角度
• 引导程序

该产品具有不同的模块，这些模块由服务器中的目录分隔.这些模块也是我的BitBucket中的单个存储库.

The product has different modules separated by directories in the server. These modules are individual repositories in my BitBucket as well.

幸运的是，所有模块都使用相同的数据库.在代码级别，对诸如数据库名称，URL(用于访问API，指向服务器中其他文件夹的资产)之类的配置进行了硬编码.

Fortunately, all the modules use the same database. In a code level, the configurations such as Database name, URLs (to access APIs, assets that point to the other folders in the server) are hard-coded.

我们有4个实例(开发，生产，abc，abcdev).每个实例的硬编码配置都不同.我最近才实现了Git，并将所有代码推送到服务器中.

We have 4 instances (dev, production, abc, abcdev). The hard-coded configurations are different for each instance. I have implemented Git very recently and have pushed all the code into the server.

范围是维护单个存储库，并为不同的实例提供不同的分支.由于值在很多地方都是硬编码的，因此分支之间的合并将非常困难

The scope is to maintain a single repository and have different branches for the different instances. Since the values are hard-coded at so many places, merging between the branches would be very difficult

我认为应该处理的方式是，创建另一个名为config的模块，大概添加一个json文件，该文件中将包含URL和数据库相关信息.

The way I feel I should be handling it is, to create another module named config, add presumably a json file that would have the URLs, database related information in it.

每个分支的此文件显然会有所不同，并且在分支中不会更改此文件.尽管理论上都是如此，但我该如何实施呢?还是有其他更好的方法来处理这种情况?对于任何反馈，我们都表示感谢！谢谢！

This file would obviously be different for each branch and this file would not be changed in the branches. Though this is all in theory, how do I go about implement it? Or are there any other better ways to handle this scenario? Any feedback would be appreciated! Thanks!

推荐答案

首先，将所有配置选项移动到一个或多个配置文件中.使用与语言无关的格式，例如JSON或YAML.

First, move all your config options into a configuration file (or files). Use a language agnostic format such as JSON or YAML.

将配置文件/目录放在容易找到的源树顶部.

Put the config file/directory at the top of the source tree where it's easy to find.

范围是维护单个存储库，并为不同的实例提供不同的分支.

一个回购是好的.不同的分支不是.快速管理许多长期存在的分支机构变得很复杂.

A single repo is good. Different branches are not. Managing many long-lived branches rapidly gets complex.

相反，只有一个长期存在的分支，可能是master. 使用功能分支隔离开发，并在允许其合并之前进行质量检查进入master.这样，master总是可以使用.直接从master部署.

Instead have a single long-lived branch, probably master. Use feature branches to isolate development and have them QA'd before they're allowed to merge into master. That way master is always ready to go. Deploy directly from master.

这就是可能的样子.每个字母都是一次提交.每个[branch]是一个分支头.

Here's what that might look like. Each letter is a commit. Each [branch] is a branch head.

                      I - J   L - M - N [feature1]
                     /     \ /
A - B - C ----- F - G ----- K [master]
         \     /             \
          D - E               O - P [feature2]

这显示了两个完整的功能，D - E和I - J，已经通过了质量检查并已合并到master中.由于已经在功能分支上完成了质量检查，因此将master部署到生产中.有两个开放的功能分支，每个分支定期运行git rebase master，因此它们是最新的，经过全面测试的代码.

This shows two completed features, D - E and I - J, have already passed QA and been merged into master. Since QA has already been done on the feature branches, master is deployed to production. There are two open feature branches, each of which periodically runs git rebase master so they are up to date with the latest fully tested code.

请注意，没有 no 直接提交给master，它只能通过功能分支合并来更改.这意味着master始终经过测试，可靠并且可以部署.进行中的各个功能不会互相干扰，可以依赖稳定的master分支；如果有什么问题，他们知道这是因为他们的工作，而不是因为有人打破了dev分支.

Notice there are no direct commits to master, it only changes via a feature branch merge. This means master is always tested, reliable, and ready to deploy. Individual features in progress don't interfere with each other and can rely on a stable master branch; if something breaks they know it's because of their work, not because someone broke the dev branch.

那不同的配置呢?

每个分支的此文件显然都不同，并且在分支中不会更改此文件.

在不同的分支中具有相同的配置文件是一种解决冲突的好方法，人们会意外地用测试和开发信息覆盖该配置.

Having the same config file be different in different branches is a great way to get conflicts and people accidentally overwriting the config with test and development info.

拥有一组配置文件更简单，这些配置文件具有针对所有不同上下文的配置，以及它们共享的默认设置.

It's simpler to have one set of config files which has configurations for all the different contexts, plus a default for them to share.

例如，您的数据库配置可能类似于 YAML 中的以下内容.

For example, your database config might look like the following in YAML.

default: &default
  adapter: postgresql
  encoding: unicode
  username: postgres

development:
  <<: *default
  database: myapp_development
  host: localhost

test:
  <<: *default
  database: myapp_test
  host: localhost

production: &production
  <<: *default
  host: our.production.server
  username: production_db_user

client1:
  <<: *production
  database: client1

client2:
  <<: *production
  database: client2

这使用 YAML锚点和别名进行覆盖，<<: *default说要包括该节点标记为&default.这消除了各种上下文之间的大量冗余.

This uses YAML anchors and aliases to do the overlays, <<: *default says to include the node marked with &default. This eliminates a lot of redundancy between the various contexts.

让您的应用从环境变量中选择环境，或者从上下文中进行猜测.

Have your app choose the environment from an environment variable, or guess it from context.

这是Rails的工作方式，多个配置文件，每个都有针对每个上下文的配置部分.

This is how Rails does it, multiple configuration files, each with configuration sections for each context.

下一步是从源代码中删除生产机密，并将其放入环境变量中.机密是诸如密码和API密钥之类的东西.然后，当您的生产系统启动时，将使用设置的这些环境变量启动它们. 这就是诸如Heroku之类的云托管站点的工作方式.

The next step is to take production secrets out of the source code and put them into environment variables. Secrets are things like passwords and API keys. Then when your production systems are started, they're started with those environment variables set. This is how cloud hosting sites such as Heroku do it.

或者，您可以在配置文件中对生产秘密进行硬编码，但可以对其进行加密.然后通过环境变量提供解密密钥.这意味着您只需要一个环境变量即可进行生产，如果要迁移旧系统，这可能会更简单. 这是TravisCI的工作方式.

Alternatively you can hard code the production secrets in your config files, but encrypted. Then supply the decryption key via an environment variable. This means you only need one environment variable for production, which might be simpler if you're migrating an old system. This is how TravisCI does it.

这可能是一堆工作，具体取决于当前现有系统和工作流的设置方式，但这是一个非常成功的模式.

It might be a bunch of work, depending on how your existing system and workflow are currently set up, but this is a very successful pattern.

这篇关于如何在我的产品中在Git级别具有多个模块的情况下处理硬编码的URL和数据库配置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！