SaaS应用12原则：（三）配置
在环境中存储配置
通常，应用的配置在不同部署(预发布、生产环境、开发环境等等)间会有很大差异。这其中包括：
- 数据库，Memcached，以及其他后端服务的配置
- 第三方服务的证书，如 Amazon S3、Twitter 等
- 每份部署特有的配置，如域名等
有些应用在代码中使用常量保存配置，这与 12-Factor 所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在大幅差异，代码却完全一致。
判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。
需要指出的是，这里定义的“配置”并不包括应用的内部配置，比如 Rails 的 config/routes.rb，或是使用 Spring 时代码模块间的依赖注入关系。这类配置在不同部署间不存在差异，所以应该写入代码。
另外一个解决方法是使用配置文件，但不把它们纳入版本控制系统，就像 Rails 的 config/database.yml 。这相对于在代码中使用常量已经是长足进步，但仍然有缺点：总是会不小心将配置文件签入了代码库；配置文件的可能会分散在不同的目录，并有着不同的格式，这让找出一个地方来统一管理所有配置变的不太现实。更糟的是，这些格式通常是语言或框架特定的。
12-Factor推荐将应用的配置存储于环境变量中（ env vars, env ）。
环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。
目前特别流行的docker是可以很容易地满足这个需求
配置管理的另一个方面是分组。有时应用会将配置按照特定部署进行分组（或叫做“环境”），例如Rails中的 development,test, 和 production 环境。这种方法无法轻易扩展：更多部署意味着更多新的环境，例如 staging 或 qa 。 随着项目的不断深入，开发人员可能还会添加他们自己的环境，比如 joes-staging ，这将导致各种配置组合的激增，从而给管理部署增加了很多不确定因素。
12-Factor 应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。
总结
使用代码常亮的坏处：
- 修改配置必须修改代码
- 部署时需要不同配置，无法进行代码的管理
使用配置文件的坏处：
- 容易提交到代码库里
根据环境对配置进行分组的坏处：
- 不正交
计算机中的正交
在计算技术中，该术语用于表示某种不相依赖性或者解耦性。如果两个或者更多事物中的一个发生变化，不会影响其他事物。这些事物就是正交的。在设计良好的系统中，数据库代码与用户界面是正交的：你可以改变界面，而不影响数据库，或者更换数据库，而不用改变界面。
12-Factor推荐将应用的配置存储于 环境变量 中，保证配置排除在代码之外，有如下好处：
- 环境变量是一种清楚、容易理解和标准化的配置方法
- 环境变量可以非常方便地在不同的部署间做修改，却不动一行代码
- 与配置文件不同，不小心把它们签入代码库的概率微乎其微
- 与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关
- 存储在环境变量中的另一个好处是，方便和Docker配合使用
参考：
