作者介绍
陈能技，DBAplus社群原创专家，新炬网络首席DevOps专家。14年开发测试与质量架构经验，擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。
业界关于持续交付有如下图所示的5级能力成熟度模型：
今天我们就来聊聊持续交付流水线中的环境配置管理工作。
DevOps、持续交付、环境配置管理
持续交付作为DevOps的核心实践，涵盖了从开发到测试到部署上线的过程，是持续集成的延伸，持续交付流水线中涉及很多环节，而每个环节基本上都跟环境配置管理相关。
例如开发阶段的构建环境、联调环境、测试阶段的功能测试环境、性能测试环境、安全测试环境、兼容性测试环境，发布生产前的准生产部署环境等。
整个开发环境可分为本地开发环境，测试环境，准生产环境，生产环境。当产品通过了各种测试，例如: 功能测试，性能测试，系统测试等等，需要部署到准生产环境，其特点是与生产环境参数基本一致，在用户接受测试通过之后，可根据业务需求或决策部署在生产环境了。
传统模式下的环境配置管理问题
DevOps的目标是通过建立并不断完善持续交付的流水线，最终达到无需人工干预的持续交付过程。从代码开发到持续集成，创建测试环境，运行测试并报告结果，完成各种测试计划中任务，最后是业务决策交付或部署上线。
下图是一个典型的持续交付流水线，可以看到流水线经过了好几套环境的测试、验证，可见环境配置管理工作的重要性。
传统模式下的环境配置管理通常存在以下问题：
1、手工准备环境，对冲突无控制。
-
软件安装麻烦、来源不一致、安装方式不一致、杂乱无章。
-
共用一个服务器开发环境，隔离性差，互相冲突。
-
可移植性差，例如和生产环境不一致，开发人员之间也无法共享；新人入职通常又折腾一遍开发环境，无法快速搭建。
2、基础设施环境的准备工作繁琐，跨部门流程冗长
3、手工部署软件
部署和发布过程以及发布后的验证都依赖人工进行，容易出错，并且效率有待提升。
4、环境资源无法共享
环境资源缺乏动态调配能力，造成资源浪费。
环境配置管理与应用部署自动化
为了有效解决上述问题，提高持续交付流水线的效率，我们需要开展环境集中配置管理的工作。主要从以下几方面入手：
-
基础设施环境配置管理
基础设施（Infrastructure）代表了你所在组织中的所有环境，以及支持其运行的所有服务，如DNS服务器、防火墙、路由器、版本控制库、存储、监控应用、邮件服务器，等等。
基础设施管理的基本原则：
（1）使用保存于版本控制库中的配置信息来指定基础设施所处的状态；
（2）基础设施应该具有自治特性，即它应该自动地将自己设定为所需状态；
基础设施不但应该具有自治特性，而且应该是非常容易重新搭建的。当出现硬件或其它问题时，就能迅速重建一个全新的已知状态的环境配置。所以，基础设施的准备工作也应该是一个自动化过程。自动化的准备工作与自治性的维护相结合，可保证一旦出现问题就能在可预见的时间内重建基础设施。
（3）通过监测手段，应该每时每刻都能掌握基础设施的实时状况。
应该与交付流程的其它方面一样，把创建和维护基础设施需要的所有内容都进行版本控制：
（1）操作系统的安装定义项（例如使用Debian Preseed、RedHat Kickstart和Solaris Jumpstart）。
（2）数据中心自动化工具的配置信息，例如Puppet、CfEngine等。
（3）通用基础设施配置信息，例如DNS区域文件、DHCP和SMTP服务器配置文件、防火墙配置文件等。
（4）用于管理基础设施的所有脚本。
部署流水线的基础设施变更管理工作：
（1）对于任何基础设施的变更部署到生产环境之前，应该验证所有的应用程序在这些变更之后也能正常工作，并确保在该新版本的基础设施之上，所有受到影响的应用程序的功能和非功能测试都能成功通过。
（2）将这些变更应用到测试和生产环境上。
（3）流水线应该执行部署测试，确保新的基础设施配置已成功部署。
基础设施的版本配置管理工作还包括：
管理应用程序和应用程序所依赖的基础设施之间的版本依赖。也就是说，为了能够正常工作，就要记录每个应用程序需要哪个版本的基础设施。应用部署与发布管理
良好的环境配置管理能为应用部署和发布创造高效的环境，而应用部署与发布工作本身也应该做集中化的配置管理工作。例如，制定完善的发布计划：
1、第一次部署应用程序时所需的步骤；
2、作为部署过程的一部分，如何对应用程序以及他所使用的服务进行冒烟测试；
3、如果部署出现问题，需要哪些步骤来撤销部署；
4、对应用程序的状态进行备份和恢复的步骤是什么；
5、在不破坏应用程序状态的前提下，升级应用程序所需要的步骤是什么；
6、日志文件放在哪里，以及他包含什么样的信息描述；
7、如何对应用程序进行监控；
8、作为发布的一部分，对必要的数据进行迁移的步骤有哪些；
9、前一次部署中存在问题的记录以及他们的解决方案是什么。
对发布过程进行建模并让构建晋级：
1、为了达到发布质量，一个构建版本要通过哪些测试阶段（例如集成测试、QA验收测试、用户验收测试、试运行以及生产环境）
2、每个阶段需要设置什么样的晋级门槛或需要什么样的签字许可。
3、对于每个晋级门槛来说，谁有权批准让某个构建通过该阶段。
最后，还需要建立高效的自动化部署机制：
每个需要部署应用程序的人都能用这种自动化部署机制，而不需要了解部署本身相关的任何技术知识，一旦部署完成后，自动运行一个冒烟测试来验证部署成功与否，这样，做应用部署操作的人（包括分析人员、测试人员或运维人员）就可以确认该系统运行正常，即使不能正常运行，也很容易找到原因。
1、选择需要部署的应用程序版本之后自动执行后续的部署步骤。
2、环境及相关基础设施的准备应该以完全自动化的方式进行。
3、部署应用程序的二进制包应该从制品库中拿到，而不是每次部署时重新构建出来。
4、对应用程序进行配置。应用程序的配置信息应该以某种统一的方式来管理，并在部署和运行时使用。
5、准备或迁移该应用程序所管理的数据。
6、对部署进行冒烟测试。
7、执行测试（可能是手工的，也可能是自动化的）
8、如果应用程序的这个构建版本通过了这些测试，允许其晋级到下一个环境中。
9、如果应用程序的这个构建版本没能通过这些测试，记录一下是什么原因。
小结
本文简述了传统环境配置管理存在的问题，以及在持续交付流水线工作模式下的环境配置管理的具体做法。
随着Puppet、Ansible、SaltStack，持续集成、持续交付、DevOps，Docker、开发测试云平台等技术和方法的日渐成熟和被企业所接受，相信越往后边，持续交付流水线的环境配置管理、应用部署管理工作将越自动化、敏捷化！
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-08-08
