0

我正在开发多年来由多个开发人员开发的产品。

该产品建立在

  • PHP
  • jQuery
  • 角
  • 引导程序

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

幸运的是，所有模块都使用相同的数据库。在代码级别，数据库名称、URL（用于访问 API、指向服务器中其他文件夹的资产）等配置是硬编码的。

我们有 4 个实例（dev、production、abc、abcdev）。每个实例的硬编码配置都不同。我最近实现了 Git，并将所有代码推送到服务器中。

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

我觉得我应该处理它的方式是，创建另一个名为 的模块config，添加大概包含jsonURL、数据库相关信息的文件。

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

4

2 回答 2

1

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

将配置文件/目录放在源代码树的顶部，便于查找。

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

单一的回购是好的。不同的分支不是。管理许多长期存在的分支机构迅速变得复杂。

取而代之的是一个长寿的分支，可能是master. 使用功能分支来隔离开发并在允许它们合并到master. 这条路master随时可以走。直接从 部署master。

这就是它的样子。每个字母都是一个提交。每个[branch]都是一个分支头。

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

这显示了两个已完成的功能，D - E并且I - J已经通过了 QA 并被合并到master. 由于 QA 已经在功能分支上完成，因此master已部署到生产环境中。有两个开放的功能分支，每个分支都会定期运行git rebase master，因此它们是最新的、经过全面测试的代码。

请注意，没有直接提交master，它仅通过功能分支合并进行更改。这意味着master始终经过测试、可靠且随时可以部署。正在进行中的各个功能不会相互干扰，并且可以依赖于稳定的master分支；如果出现问题，他们知道这是因为他们的工作，而不是因为有人破坏了开发分支。

但是不同的配置呢？

对于每个分支，该文件显然会有所不同，并且该文件不会在分支中更改。

相同的配置文件在不同的分支中不同是一种很好的方式来产生冲突，人们会不小心用测试和开发信息覆盖配置。

拥有一组配置文件更简单，其中包含所有不同上下文的配置，以及它们共享的默认值。

例如，您的数据库配置在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。这消除了各种上下文之间的大量冗余。

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

这就是 Rails 的做法，多个配置文件，每个文件都有每个上下文的配置部分。

下一步是从源代码中取出生产机密并将它们放入环境变量中。秘密是诸如密码和 API 密钥之类的东西。然后，当您的生产系统启动时，它们会以设置的环境变量启动。这就是 Heroku 等云托管网站的做法。

或者，您可以在配置文件中硬编码生产机密，但要加密。然后通过环境变量提供解密密钥。这意味着您只需要一个用于生产的环境变量，如果您要迁移旧系统，这可能会更简单。这就是 TravisCI 的做法。

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

于 2018-05-14T02:29:33.667 回答
0

12 要素应用程序是构建现代、可维护和可扩展应用程序的固执己见的指南。

与配置相关，它告诉您将其保留在环境中。推荐的方法是使用环境变量。

十二因素应用程序将配置存储在环境变量中（通常缩写为 env vars 或 env）。环境变量很容易在部署之间更改，而无需更改任何代码；与配置文件不同，它们被意外签入代码仓库的可能性很小；与自定义配置文件或其他配置机制（如 Java 系统属性）不同，它们是与语言和操作系统无关的标准。

于 2018-05-14T02:37:46.223 回答