IT持续交付

春节前与同事讨论CD（持续交付）的技术方案，发现主流的技术方案是软件交付最后一公里的“AD”（自动化部署）。站在本系列文章提到四个关键价值的“提升交付速度”这个运维价值看，单纯的自动化部署主要将部署/回切工作从1小时提升到5分钟的效率能力上。而在端到端的IT交付价值链中，部署是其中一个节点，所提升的55分钟只占整个IT交付链路中的一部分，更大的消耗是在节点与节点之间的协同。所以，“持续交付”应该跳出“部署”，站在整个IT交付链路，关注节点的自动化、节点与节点之间的连接线，通过标准化、流水线、自动化、相关工具链打通等工程性工作的落地，提升整个IT效能。

本文为《数智万物下的运维思考》第2部分“流程”第2章“变更”的“持续交付”。

1.聊聊“持续集成、持续交付、持续部署”

在做持续交付项目中，我们经常会遇到持续集成、持续交付、持续部署三个词，不同的人对这些词的理解有所不同。理清技术名称概念、作用、内涵，有助于设计正确的持续交付技术方案，提前落实技术与流程标准，提升架构的扩展性。比方说，运维可能容易将持续交付理解为程序自动化分发，重点解决程序向多台主机的下发的自动化，或将持续交付做成运维内部的独立工具，这与“持续”关注的完整流畅的流水线、“交付”关注的用户价值交付有所不符。理解不对，还将影响你在项目资源申请、标准化制定的范围、流程设计、关联系统的互通、技术架构设计的完整性与扩展性。

“持续集成、持续交付、持续部署”这三个概念都有“持续”两个字，单从“持续”两个字，我觉得强调软件交付流水线前后环节之间的连续性、自动化、质量内建、精益管理。“集成、部署”则是软件研发、测试、运维对于软件交付的环节，常见定义如下：

持续集成（CONTINUOUS INTEGRATION），即CI，是软件开发周期的一种实践，把代码合并、构建、（单元）测试集成在一起，不断的将代码合并到主干然后自动进行构建和测试。

持续交付（CONTINUOUS Delivery），即CD，是在CI的基础上完成软件构建，不断的将软件持续部署到测试、准生产、生产等环境，并在相应环境进行操作，目标是将软件产品交付给用户。

持续部署（CONTINUOUS DEPLOYMENT），即CD，即持续部署，是持续交付最后一公里的工作，是完成审核后，将软件自动化部署到测试、准生产、生产环境。

从上面三个定义看，持续集成以“构建”程序到制品库为界，持续部署以将二进制程序与配置部署到环境为界。持续交付的边界有两种观点，一种是持续交付介于持续集成与持续部署之间，强调软件一直处于可交付的能力；另一种是持续交付包括了部署。我倾向于后者，本篇文章提到的持续交付指持续集成结束后的动作，包括：研发提交、测试人员部署（或回滚）测试/验收环境、测试人员测试、运维人员部署（或回滚）生产环境。涉及的技术模块：程序版本管理工具、环境配置管理工具、制品库、自动化测试工具、自动化发布/部署工具，以及监控、CMDB、ITSM等工具、云平台的互联互通。

2.从IT价值看持续交付

1）DevOps与SRE、持续交付

关于价值我在前面提到过数字化转型下的运维价值与运维角色的变化，所以思考持续交付价值，先看看持续交付与DevOps、SRE的关系。

DevOps是一组过程、方法与系统的统称。虽然从词语来看包括Dev（开发）、Ops（运维），实际应该包括开发、质量、运维3个团队之间的沟通、协作与整合。DevOps是一套实践框架，包含了精益、敏捷的理念，各种持续集成和持续交付的职能，以及构建流水线的工具。

SRE（Site ReliabilityEngineering，站点可靠性/稳定性工程师），要从其名称看看SRE的岗位角色。S（site），最初代表www.google.com的运维服务，随着团队的扩大，实际上S的范围也扩展到了其它应用系统。R（Reliability），google认为是运维组织要不断的优化系统架构、运维流程，让系统更加可靠，扩展性更好，能更有效的利用资源。

SRE与DevOps的关系，我觉得有几点：

一是两者关注点不一样，DevOps属于一种文化与方法，定义的扩展空间比较大，关注软件交付的生命周期，强调软件交付流水线的自动化、交付速度。SRE作了相对明确的定义，明确强调了“可靠性”保障，这推动了SRE聚焦资源落到尽可能增加MTTF（不出故障的时间）和缩短MTTR（出故障后的恢复时间）两个指标上，并围绕这两个关键指标加强系统运行风险排查与解除，并加强风险发生后的应急能力。E（工程师），工程师需要具备有工程能力，在google指需要具备软件研发能力的工程师，能够和业务研发团队共同工作，研发系统以外的额外组件。

二是SRE是DevOps的一种实践。从运维角度看，两者需要的技能都区别于传统运维角色的业务连续性保障，需要增加研发能力；从研发角度看，SRE还强调了对应用运行可靠性的掌控。从实践看，SRE通常在运维团队中践行，所以站在金融行业，我觉得SRE中对于“业务”的理解可能需要更多，在工程角度加以辅助。SRE在工程角度的实践是DevOps的一种实践。

说完成DevOps与SRE的关系，再看看与持续交付的关系。持续交付是DevOps的一种主流的技术实践，两者最终目的都是为了更快向用户交付高质量的软件交付。区别是，持续交付更专注于具体实现，是DevOps方法与文化在组织、流程、工具上的实现。

2）归纳价值

快速交付

貌似这个价值勿需多言，持续交付就是为了更快的向用户交付高质量的软件。企业数字化转型下，业务最重要的能力是快速适应复杂性与不确定性的环境，对于企业内的IT组织相应的最重要的能力就是快速交付数字化产品，数字化产品通常以软件形式表现。

l 提升效能

全线上的代码管理，丰富的研发工具运用，自动化的构建、测试、发布，在线、透明的协同，以及持续交付带来的组织、流程的改进，都将赋能于员工，大大提升研发、测试、运维效能，从而完成更多的需求。

l 精细化管理

线上化的交付过程，自动化重复性、操作性的低价值工作，将过程数字化，有助于精细化管理：

减少手工操作，降低操作风险；

全线上化、自动化将会流水线，有助于消费浪费，走向精益；

数字化执行过程，有助于量化代码管理、质量管理、负荷管理、风险管理、应急管理等能力，为持续提升运营水平提供数据基础。

3.发布流水线

发布流水线是将一个软件发布环节串起来，让软件交付过程中不同的角色可以透明的看到整个过程。同时通过线上化各环节的执行步骤就能够量化持续交付的水平，比如：自动化测试覆盖率、缺陷数量、每天构建次数、发布平均时长等，量化数据能让团队清晰的看到低效环节并进行改进。持续交付的一个基本发布流水线通常包括提交、测试、生产部署（或回滚）3个步骤，围绕这3个步骤画了一张图，大致意思是：

春节前与同事讨论CD（持续交付）的技术方案，发现主流的技术方案是软件交付最后一公里的“AD”（自动化部署）。站在本系列文章提到四个关键价值的“提升交付速度”这个运维价值看，单纯的自动化部署主要将部署/回切工作从1小时提升到5分钟的效率能力上。而在端到端的IT交付价值链中，部署是其中一个节点，所提升的55分钟只占整个IT交付链路中的一部分，更大的消耗是在节点与节点之间的协同。所以，“持续交付”应该跳出“部署”，站在整个IT交付链路，关注节点的自动化、节点与节点之间的连接线，通过标准化、流水线、自动化、相关工具链打通等工程性工作的落地，提升整个IT效能

1) 制品库、版本管理与持续交付

制品库通常针对于程序构建后的二进制文件，进入交付流水线提交环节之后的制品应该保持不可修改（也就是说只在提交环节生成制品），出现问题需要采用精益思想，即时中断并解决，重复提交优化后的制品。

版本管理在CI环境也出现，主要是针对代码的版本管理，比如GIT、SVN等。在持续交付环节也涉及版本管理，比如制品的版本管理、配置文件的版本管理等。

通常来说，持续交付的一个基本发布流水线通常包括“研发提交、测试人员部署（或回滚）测试/验收环境、测试人员测试、运维人员部署（或回滚）生产环境”几个步骤。研发人员提交环节涉及将程序从代码版本库中编译、打包、创建为二进制包，并将二进制包写入制品库。测试与运维人员则从制品库中获得待部署的二进制包，并根据配置管理的环境与版本管理，发布到不同的环境。

2) 流水线环节

提交环节

通常是研发认为软件满足了交付条件，将软件代码从代码库中编译、代码分析、打包等操作，并以二进制包文件的方式存入制品库。这个过程生成的二进制包文件将流转在后面整个交付流水线，流水线上不同的测试角色、运维角色到制品库获取这个二进制包。二进制包只在提交环节生成一次，即部署在不同环境的二进制包应该与通过前面流水线步骤流程中的二进制包完全一致，所以通常会在流水线进行包的一致性检查，如果某个环节失败就要停下来确认是否回到提交环节重新生成新的二进制包。因为二进制包只生成一次，而不同环境的部分配置会不同，所以有必要将环境配置进行单独管理，比如为每个环境保存与环境相关的配置文件，并对配置文件进行版本控制。

测试环节

持续交付过程中的测试通常包括：服务端测试（接口，性能，安全），再进行客户端测试（UI验收，兼容性，性能，安全），或按：冒烟测试（部署测试）、功能验收测试、容量/性能/安全性测试、易用性/探索性测试等来分类。在持续交付中讲测试，强调自动化，哪些可以自动化借鉴《持续交付发布可靠软件的系统方法》的一张图，具体的情况因为非测试专业，这里不过多展开。

部署生产

部署生产就是将二制包在生产环境分发，并对环境配置、数据库等进行部署。部署环节通常可以分解为几个步骤：获取发布二进制包文件、包文件校验、环境预处理（如：停止服务、环境验证）、程序备份、数据备份、数据变更、程序更新、配置修改、启动服务、技术检查等。发布流水线的主要思路是每次变更都要在流水线多个环境部署，假设团队实现了定期程序构建并生成二进制包，测试环境自动进行冒烟、功能、容量等测试，且每个环境的部署方式一样，那么生产部署就能达到理想的持续部署。所以，对于自动化部署来说，环境配置管理与流水线上不同环境采用相同的部署方式两点是关键。发布流水线在运维日常变更发布工作中很常见，就算企业中没有持续交付的系统，很多团队在局部也沉淀下来了不少自动化脚本，可以考虑把这些自动化脚本串起来作为生产部署流水线的切入点。

3) 关联工具

在上图右边是一些关联工具应用。首先，从工具角度看发布流水线，需要有一个在线编排的功能，能够对流水线上的不同环节进行编排。其次，对于环境主机要有自动化程序分发的基本能力，通常采用脚本执行的方式。另外，自动化测试涉及的工具很重要，需要与自动化测试平台对接。同时，还需要与运维的CMDB、监控、日志、堡垒机等打通。

4.全配置管理

在《持续交付》一书中，对配置管理作了如下定义：“是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索”。从这个定义看，配置管理不仅是配置文件的管理，而是一种全配置管理思路，包括以下信息：

程序代码、制品。强调有效的程序程序的主干、分支管理、版本管理，以及依赖库文件、组件的管理。

环境配置管理。关注依赖特定硬件、软件、基础设施、运行环境等涉及的配置文件管理。

应用配置管理。区别于代码、环境配置的软件配置，我觉得包括代码配置与其它软件配置，代码配置即软件运行涉及的相关配置文件，通常由研发在工程中通过ConfgServer进行管理，我个人认为也可以把这类配置划到程序代码范围；其它配置包括文档、打包时涉及的配置信息、部署软件时涉及的配置、部署脚本、数据库脚本等配置信息。（相对来说，应用配置范围我还没有特别明确，有兴趣的同学欢迎加微信huashengpeng-001一起聊聊）

配置管理是持续发布的一个基础性、必要的能力。没有配置管理，也就是应用程序源代码、构建脚本、测试、文档、数据库脚本、二进制软件制品、代码库、软件配置文件、环境配置文件都失去了版本控制、依赖控制。一线互联网企业会建立一个统一的配置中心将配置与程序代码分离，但在金融行业这种方式相对较少，或小范围实践。

5.从工具角度看持续交付

持续交付有一套相对成熟的工具链，在实际落地情况，需要结合公司已经有的基础工具实施情况进行实施。事实上，企业里面不少系统或多或少已经沉淀了一些部署相关的自动化脚本或工具，在工具建设过程中可以考虑利用好存量工具，以部署流水线为切入点，实现流水线编排、流水线各环节的自动化执行、打通关联工具链路，构建端到端的软件持续交付系统。结合上面的小结，我觉得持续交付工具主要包括以下几部分：

与部署流水线相关的自动化。部署通常会被理解为程序部署，比如获取发布二进制包文件、包文件校验、停止服务、环境验证、程序备份、数据备份、数据变更、程序更新、配置修改、启动服务、技术检查、回滚等涉及的流水线步骤，通常涉及流水线的编排、脚本执行、配置修改、文件分发等。除了软件程序部署以外，以全配置管理角度看看部署，还包括环境部署、数据变更，配置变更等，所以系统在设计上要融入到整个IT架构中，比如要与IAAS的CMP打通进行部分环境配置，与PAAS平台打通进行容器的发布等。

融合与文件及版本管理相关的代码版本管理、制品库、配置管理。

打通与工单流程相关的研发管理系统、测试管理系统、运维（ITSM）。

打通与测试相关的自动化测试工具，与生产相关的监控、问题定位（日志）、环境（堡垒机）等。

数字化持续交付。度量软件交付全流的效能提升，可视化具体发布的交付环节、版本等。