dotenv是否与Twelve-Factor App相矛盾？

Question

我已经阅读了Twelve Factor App's Config - Section III，并在NodeJS中搜索了一种方法。似乎大多数人建议dotenv将配置存储在环境变量中。

然而，似乎dotenv与Twelve-Factor App相矛盾，因为状态：

  

配置的另一种方法是使用未检入修订控制的配置文件，例如Rails中的config / database.yml。这比使用在代码库中检查的常量有了很大的改进，但仍有缺点：很容易错误地将配置文件签入到repo中;配置文件倾向于分散在不同的地方和不同的格式，这使得很难在一个地方查看和管理所有配置。此外，这些格式往往是语言或框架特定的。

     

十二因素应用程序将配置存储在环境变量中（通常缩写为env vars或env）。在不更改任何代码的情况下，可以在部署之间轻松更改Env变量;与配置文件不同，它们几乎没有机会被意外地检入代码仓库;与自定义配置文件或其他配置机制（如Java系统属性）不同，它们是与语言和操作系统无关的标准。

理解这个陈述，似乎使用dotenv，你将创建一个配置文件.env，然后将它们导出为环境变量。

这不会违反十二因素应用程序，因为.env文件会被意外检入代码仓库吗？

Answer 1

直到某人实际提交并推送.env时才会违反12因素;）

.env文件也可以存储在repo本身之外，因为库或应用程序仍然必须读取.env文件并将变量推送到环境中。根据您的实施情况，这可以简单到将路径从".env"更改为"../.env"。

使用.env文件可以很好地让开发人员轻松管理环境，但仍然可以在部署期间与更好的环境实践兼容。我可能在虚拟机中运行30-40个12因子风格的应用程序，并且必须单独管理每个环境是没有像.env这样的“垫片”而令人生畏。

Answer 2

大多数版本控制系统都有忽略某些文件的方法。

Git有.gitignore

SVN有"Special Ignores"

作为旁注，这些技术同样用于忽略node_modules目录，以避免不必要地复制文件。

Answer 3

OP 提出了一个深思熟虑的问题。

我认为 dotenv 与第 3 节的 12 因素相矛盾，原因有两个。

1. 根据定义，即本段：“另一种配置方法是使用未签入版本控制的配置文件，...仍然存在弱点：很容易错误地签入配置文件到 repo; ...（因此 12-factor 应用程序使用不同的方法作为）将配置存储在环境变量中”，现在您明白了，只是因为可以/应该声明 .env 文件在 .gitignore 中，不会使 dotenv 免于“容易错误地将配置文件签入存储库”审查。

2. 如果应用程序从并且仅从 env var 读取配置，则它可能完全符合 12 因素第 3 节的要求。但是 dotenv 功能是允许应用在可用时自动选取 ./.env。从这个意义上说，.env 文件 - 尽管它的名称具有欺骗性 - 是一个配置文件，彻头彻尾。同样，这属于 12 因素明确避免的配置方法类别。

话虽如此，dotenv 仍然是可行的选择之一。其他选项包括：在 docker 层管理环境变量；或在 unix 用户的 .*rc 文件中；或在网络服务器配置中；或在 /etc/profile 中（引用自 this another SO post）。 dotenv 提供了一种最通用的文件格式（fwiw，docker env_file 同样简单明了，尽管它们的规格不同），但是 dotenv 是唯一一种“污染”目标应用程序代码库的解决方案依赖。

最重要的是，dotenv 很好，有趣的是，许多 dotenv 实现都继承了它从 12 要素应用原则开始的说法，但只有少数人承认它的 {{1} } 方法偏离了 12-factor app。