原始的12因素只是声称你需要将配置存储到环境里面，但是我觉得配置这条规则应该需要更清晰一点
把配置，凭证和代码当作易挥发的物质，这些物质一旦合并会发生化学反应
这听起来可能有点苛刻，但如果不遵守这条规则，可能会给您带来难以言表的挫折感，离应用程序上线越近越会产生问题
为了能够把配置和代码、证书隔离开，我们需要对配置有一个清晰的定义。配置指会随着部署环境发生变化的值，这个包括：
- 后端服务的URLs和其他信息，比如web service和SMTP 服务
- 连接到数据库的必要信息
- 调用第三方服务比如Amazon AWS， Google Maps, Twitter, and Facebook的证书
- 可能需要放到XMl或者YMAL配置文件的其他属性
配置并不包括程序本身的内部信息，也就是说，如果某一个值在所有的部署环境都是一样的（很明显他是你的不可变的build artifact的一部分），然后它就不是配置
证书是极其敏感的与代码无关的信息，通常来说，程序员会把证书从程序源代码里面提取出来让好把他们放到属性文件里面，但是这样做并没有解决问题。因为配置文件本身仍然是代码仓库的一部分，这意味着证书与你的程序一起发布，这本身就打破了这条规则
把你的程序当作开源项目，一个最简单的检验你的证书和配置是否合理的方式，就是假设你现在需要把你的源代码push到GitHub上面
如果外面的人需要访问你的代码，你是否把你依赖的服务的敏感信息给暴露出去了呢？不是你的组织内部的人是否看到了内部后端服务的URLs，证书或者其他敏感的信息呢？
如果你能够在不暴露任何敏感信息的情况下去开源你的代码，那么你可能在隔离你的代码、配置、证书方面做的很好了
不把证书暴露出去是显而易见的，但是不把外部配置暴露出去却显得不那么好理解。外部化的配置能够帮助我们通过CD管道把不可变的builds部署到不同的环境，同时管理自己的开发和生产环境
都知道要将配置外部化，但是实施起来却不是那么回事了。举几个例子，如果你正在开发一个Java程序，然后你将自己的配置放到属性文件，并且与代码放到一起构建，其他类型的语言可能会有一个YAML文件，.NET程序会有一个XML文件
你应该想到上面的所有做法都是不符合云原生模式的，所有的场景都会由于跨环境可变的配置而导致你无法你构建一个不可变的release artifact
有一种比较笨的外化配置的方法是把你的所有代码里面的配置文件全部抽出来，然后修改你的代码从环境变量去读取。环境变量被认为是外部化配置的最佳实践，尤其是在Cloud Foundry或Heroku等云平台上
根据您的云提供商，您可能可以使用其工具来管理后端服务或绑定服务，以安全的方式向应用程序公开包含服务凭证和URL的结构化环境变量
另外一个推荐的外化配置的方式是使用一个配置中心，比如开源的Spring Cloud Configuration Server，或者其他的也有不少。购买配置服务器产品时应注意的一件事是支持版本控制。如果要对配置进行外部化，则应该能够保护数据更改并获得由谁进行更改以及何时进行更改的历史记录。正是这一要求可以使用仓库版本控制系统比如git来作为一个配置服务器