3 、部署时注入配置的技术
部署时注入配置的技术，从实现原理上就是把通用的配置信息作为默认配置项，然后定义一系列占位符，用于替代那些特定环境有差异的配置项。然后在部署时，通过适当的方法用实际的配置项覆盖掉这些占位符。但需要注意的是，要尽量减少差异化的配置项，只保留与应用系统运行环境紧密相关的配置项。并且，最好能对配置项的覆盖过程进行校验，防止因配置失误导致整个部署失败。
有一个经常使用的开源工具AutoConfig，类似于Maven Filtering的工作方式，该工具与应用所采用的技术、框架完全无关，对应用完全透明，具有良好的通用性。值得一提的是，这个工具成功解决了Maven Filtering在替换配置时需要重新Build的问题，即不需要重新获取源码并Build，就可改变目标文件中所有配置占位符的值，达到部署时动态修改配置的目的。详细介绍如下表所示：
在公司内部，针对一些定制化的场景，我们也自己开发了配置注入的相关工具，从实现的原理和效果来看都是比较类似的。
五、环境的配置管理
上面我们介绍过，持续交付的产出应该是可正常运行的应用系统而不仅仅是可工作的软件，系统运行起来除了应用程序本身，还依赖于硬件、操作系统、中间件，以及各种库文件等。前面介绍了分支和代码、构建产物、应用配置的管理，下面我们重点介绍环境的配置管理。
在环境配置管理的领域，随着所管理服务器的规模不断增长以及业界新技术和新工具的应用，其发展过程中一般会经历以下三种模式：
· 雪花片服务器
这可能是很多公司都经历过的，比较原始的服务器管理状态。任何一片雪花看起来差不多，但实际上细节都是不一样的。对于服务器的管理也是这样，我们的服务器经过长年累月的运行，各种操作系统和软件的升级、更新，以及手工执行的各种黑科技的补丁，都会造成服务器间有细微的差别。如果某一天一台服务器宕机了，其实很难再建出一台一模一样的出来，因为配置过程已经无从追溯了。所以这种模式的主要问题是：反复修改带来不确定性和风险，环境的重建困难。
· 自动化、配置化的环境管理
上图中在这个模式下列举了很多环境配置管理工具，如Puppet、Chef、Ansible、SaltStack等，它们能够以自动化的方式管理操作系统及其之上的整个运行时环境。通过这些工具，可以用易于理解、声明式的方式定义环境中需要安装什么软件、启动什么服务、修改什么配置等等，这些声明具备幂等性的特点，反复运行是安全的。并且，我们可以将这些声明式的定义保存在版本控制库中，这样就记录了每次变更的完整过程，相当于对环境的所有修改具备了完整可追溯的能力。下表对这几款常见的环境配置管理工具进行的简单对比。
· 不可变服务器（Immutable Server）
随着容器技术的广泛应用，很多应用的部署演进到了不可变服务器的模式，就是任何的变更都打在镜像里面，用镜像进行各级测试，最终通过测试后使用镜像上线，上线后不做任何变更，直到被新的实例替换掉。这种模式更这也符合持续交付原则：只构建一次，在所有环境运行。Docker提供了一种应用封装的标准格式，可以用来创建在开发、测试和生产中可重用的容器，并且在单机层面上实现了轻量级的资源隔离，而在管理大型服务器集群时，可以应用如Docker Swarm、Kubernetes、Mesos+Marathon等集群管理系统。关于环境管理的话题本文中就暂不展开了，有机会我在持续交付模型中另外一个关键实践『环境管理』中再做详细介绍。
感谢你坚持看到了这篇文章的最后：）
总结一下，刚才我们重点介绍了持续交付模型诸多实践的其中一个：『全面配置管理』，分别从代码和构建产物的配置管理、应用的配置管理、环境的配置管理三个层面进行了展开说明。 配置管理非常重要，只有配置管理做到位了，后续的构建管理、持续集成、测试管理、环境管理、部署管理以及整个交付流水线才能够比较顺利地建设起来。而配置管理想要做到位，不仅仅是使用工具，还在于对上述介绍的一系列实践的落地和坚持。
希望本文对大家奠定持续交付的实施基础，以及未来真正走上持续交付之路能有所帮助，后面有机会再跟大家继续分享持续交付模型中的其他相关实践。
