Ste*_*Gee 5 environment-variables node.js 12factor
我已经阅读了十二因子应用程序的配置-第三部分，并在NodeJS中搜索了一种方法。似乎大多数人推荐dotenv将配置存储在环境变量中。
但是，dotenv似乎与“十二要素应用程序”相矛盾，因为：
另一种配置方法是使用未检入版本控制的配置文件，例如Rails中的config / database.yml。与使用已检查到代码存储库中的常量相比，这是一个巨大的改进，但仍然存在缺陷：容易将配置文件错误地检入存储库中；有一种趋势是配置文件分散在不同的位置和不同的格式，这使得很难在一处查看和管理所有配置。此外，这些格式倾向于特定于语言或框架。
十二因子应用程序将配置存储在环境变量中（通常缩写为env vars或env）。Env var易于在部署之间进行更改，而无需更改任何代码。与配置文件不同，它们很少有可能被意外检入代码存储库；与自定义配置文件或其他配置机制（例如Java系统属性）不同，它们是与语言和操作系统无关的标准。
理解此语句后，似乎可以使用dotenv创建一个配置文件.env，然后将其导出为环境变量。
由于.env文件可能会意外地签入代码存储库，因此这不会违反十二要素应用程序吗？
除非有人真正提交并推动，否则 12factor 不会被违反.env；）
该.env文件也可以存储在存储库本身之外，因为库或应用程序仍然必须读取该.env文件并将变量推送到环境中。根据您的实现，这可以像将路径从 更改为 一样".env"简单"../.env"。
使用.env文件是一个很好的折衷方案，可以让开发人员轻松管理环境，但在部署过程中仍然与更好的环境实践兼容。我可能有 30-40 个 12factor 风格的应用程序在虚拟机中运行，如果没有像.env.
OP提出了一个经过深思熟虑的问题。
\n我想说 dotenv 与第 3 部分的 12 因素相矛盾，有两个原因。
\n根据定义，即这一段：“配置的另一种方法是使用未签入版本控制的配置文件，...仍然有弱点：它\xe2\x80\x99s很容易错误地将配置文件签入到repo ; ...（因此 12 因素应用程序使用不同的方法作为）将配置存储在环境变量中”，现在您知道了，仅仅因为文件.env可以/应该在 a 内声明.gitignore，并不能使 dotenv 免受“简单”的影响错误地将配置文件签入存储库”的审查。
如果应用程序仅从env var读取配置，则该应用程序可以完全遵守 12 因素第 3 节。但 dotenv 的一个功能是允许应用程序自动拾取./.env（如果可用）。从这个意义上说，该.env文件 - 尽管其名称具有欺骗性 -始终是一个配置文件。同样，这属于 12 因素明确避免的配置方法类别。
话虽如此，dotenv 仍然是可行的选择之一。其他选项包括：在 docker 层管理环境变量；或者在unix用户的.*rc文件中；或在网络服务器配置中；或/etc/profile（引用自另一篇 SO 帖子）。dotenv提供了最通用的文件格式之一（fwiw，docker env_file 同样简单，尽管它们的规格不同），但是这dotenv是唯一一种通过多一个依赖项“污染”目标应用程序代码库的解决方案。
底线dotenv是好的，有趣的是，许多dotenv实现都继承了它从 12 因素应用程序原则开始的说法，但只有少数人承认其.env方法偏离了 12 因素应用程序。