所以我一直在构建我的应用程序，主要是作为 12 因素应用程序，现在查看配置部分。
目前，我有单独的用于开发和生产的配置文件，并且通过构建过程，我们可以构建开发或生产映像。代码 100% 相同，唯一改变的是配置。
现在我 100% 明白，在 12 因素应用程序中，配置应该来自外部源，例如：环境变量，或者可能是像保险库这样的安全存储......
所以各种文章和博客没有提到配置是如何存储/处理配置的。如果代码在它自己的 git repo 中被分离并且它没有存储配置，那么我们如何处理配置？
我们是否将实际配置值存储在单独的 git 上，然后使用某种触发器通过构建过程在目标环境（Kubernet 配置映射、马拉松 JSON 配置、Vault 等）上合并/推送/执行这些值?
没有标准，但我一直在观察的是一些常见的行为，例如：
敏感信息永远不会出现在版本控制系统上，特别是作为 DCVS 的 git（您可以克隆其他位置的存储库）。如果您不关注，请记住我们现有的“安全系统”是基于在特定时间无法读取加密信息，但在特定时间点您可能能够读取信息。通常在 kubernetes 上，我看到运营商，跨多个命名空间管理服务帐户，然后其他只引用服务帐户，欢迎使用 KMS、证书管理器、Vault 等工具
像 env vars、endpoints 这样的配置是用它们自己的“生命周期”来存储和版本控制的。
12factor并不意味着将您的应用程序的配置与您的存储库分开，而是建议不要放入您的应用程序（例如在您的容器甚至二进制分发中）。
实际上，如果您只想为配置使用单独的 repo，您可以这样做，但如果您想将项目源代码放在一边，您也可以这样做。它更多地是基于项目规模、复杂性、职责分离和团队背景的决定。（恕我直言）
例如，在我的研究案例中，在专用存储库上分离配置是有意义的，因为生产环境有 50 多个集群，其中一个具有自己的隔离堆栈，还有不同的团队管理自己的服务并使用通用的支持服务（db ，api，流...）。在我看来，只要事情变得更加复杂和交叉共享，在独立存储库上分离配置就更有意义，因为多个集群上有多个团队和资源。