持续交付体系在高德的实践历程

1. 前序

对于工程团队来讲，构建一套具备可持续性的、多方面质量保证的交付体系建设，可以为业务价值的快速交付搭建起高速公路，也能为交付过程当中的质量起到保驾护航的做用。本文为你们介绍持续交付体系在高德的演进与落地。

2. 持续交付

正如前序中所总结的，咱们须要构建一套持续交付体系，从而保证在质量不降低的前提下，在业务价值交付上有更进一步的突破。那么咱们先了解一下什么是持续交付以及集团在持续交付的建设上有哪些指引。

2.1 持续交付概念

引用Martin Fowler大师在2013年时发表的文章，对于持续交付的概念有以下的解释：Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

在上述文中，能够提取几个关键词：

• 软件开发的标准化准则
• 能够作到随时随地的发布

什么状况下就能够算是团队达到了持续发布的状态呢？Martin Fowler大师也给出了标准的答案：

• Your software is deployable throughout its lifecycle
• Your team prioritizes keeping the software deployable over working on new features
• Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
• You can perform push-button deployments of any version of the software to any environment on demand

那么基于以上的观点，咱们在创建自身的持续交付体系时，须要抓住如下几个重点：

• 标准化流程流转
• 当有变动进入时，可以快速、准确且自动的获得反馈
• 解决部署问题的优先级高于功能开发
• 一键发布

2.2 集团的持续交付建设

从理论基础上对于持续交付有了初步了解后，咱们从集团层面了解一下是如何定义持续交付的能力，而且对于持续交付提出了哪些效能改进目标，参见阿里技术公众号的文章 《如何衡量研发效能？阿里资深技术专家提出了5组指标》

文章中将持续价值交付的能力拆分为3个层面的5组指标，从不一样角度对持续价值交付能力进行了衡量。

有了上面专业层面的衡量指标，那咱们是如何定义一个优秀的持续交付衡量目标呢？

管理学之父德鲁克说：“若是你不能度量它，就没法改进它”。度量帮助咱们更深入认识研发效能，设定改进方向，并衡量改进效果，因此想要进行效能提高的前提是先可以识别交付过程当中的质效瓶颈。

所以，集团在基于部分BU的优秀实践下提出了2-1-1的愿景。

• 1小时的发布前置时间是对于基础设施能力的要求，须要保证当达到交付标准后，经过交付流水线可以达到1小时内的打包、部署和验证的能力；
• 1周的开发周期涉及产品需求拆分、研发QA协做能力、持续测试以及快速反馈能力方面提出了挑战；
• 2周的需求交付周期是之前两项为基础，不只是涉及到产研测三方，还包括其余协同部门的通力合做才能保证业务价值的快速交付。

3. 持续交付在高德

在基于集团愿景的指导下，反观现有高德服务端的交付流程，咱们发如今整个流程中，存在不少效率上的竖井，这些效率问题汇总起来，便会成为整个交付流程上的效能瓶颈，进而影响业务价值的尽早交付。

咱们先从一个总体的Milestone来回顾一下整个持续交付所通过的一些重要时间节点：

• 2018/08 构思与工程能力建设：项目启动阶段，工程效率团队与业务线明确了持续交付的目标，并启动了工程能力建设
• 2018/12 初步落地与试点：项目试点阶段，完成了初步的持续交付流程搭建，并在一个项目中验证流程卡点以及质量标准的基础能力验证。最终创建了基础的质量标准以及下降流程中的耗时
• 2019/04 推动接入与平台优化：项目推动阶段，持续交付项目质量项优化并在高德的服务端的6条业务线中进行推广，在9月份完成6条业务线以及11个应用的持续交付落地
• 2019/09 复盘与展望：项目推动总结，对整个推动过程进行复盘与后续持续交付如何落地进行复盘与展望，总体产出业务推动中出现的问题以及改进方法
• 将来：在交付流程上进行贴合业务线的微创新，并对效能瓶颈点进行纵深挖掘。结合各纵向平台进行纵深挖掘，例如：覆盖率与精准回归、云歌Case平台、代码扫描平台等

经过milestone的展现，对于高德持续交付体系的演进有了大体的了解后，下面对于落地的过程以及改进的内容进行一下详细的梳理。

3.1 接入持续交付前的交付流程

首先先介绍一下在接入持续交付体系以前，高德的服务端是如何进行迭代的开发与上线的。

与大部分互联网公司同样，咱们将软件的交付拆分为多个周期，进行迭代式的交付，以便增量式的进行用户价值的交付。上图描述了一个正常迭代周期内的研发、测试以及发布的流程，咱们能够拆分为如下几个方面：

1.迭代周期起始于代码库的变动

2.在功能开发完成后，研发经过CI系统进行冒烟测试验证，保证服务能够正常启动以及基础功能可用

3.在规定的提测时间前，研发将Feature分支经过CR和MR合并到迭代分支，部署到平常环境进行提测

4.QA在收到提测邮件后，参与到平常环境的测试中

5.当平常环境测试完成后，QA会进行测试报告的产出，并确认平常环境测试经过，能够发布到预发环境

6.部署到预发环境后，会进行流量回放等测试，并最终经过线上的灰度验证，最终发布到正式环境

经过上述的图片和描述，咱们能够看到在看似完善的软件交付过程当中，却仍然存在以下一些质量、效率问题：

1.需求堆积提测、发布：

目前高德服务端大部分服务采用的是固定迭代周期进行需求发布，规划到迭代周期内的需求，不管需求大小，均须要等到迭代提测时间点进行提测，在迭代的发布窗口进行发布上线。在这种模式下，好的一点是有固定的版本节奏，总体迭代规划性比较强。可是因为提测、发布窗口固定，从而也带来了总体业务价值交付上的等待。所以，须要经过需求拆分来下降需求内部的耦合性，经过改变研发、QA的开发测试模式来下降需求提测中间的竖井等待，从而提高业务价值交付的效率。

2.质量标准不透明，没法及时反馈：

从代码提交一直到最终产品发布，通常状况下，会经历平常、预发、灰度、正式发布几个阶段，每一个阶段均有每一个阶段须要重点解决的问题以及对质量上的要求也不尽然相同。目前结果的收集汇总和通知都是经过跟版人进行人工收集和统计，并邮件通知项目成员。这样全部的标准控制都是有每一个版本的跟版人进行把控，存在信息不透明，反馈不及时的问题。经过质量项标准的创建，以及大盘结果透明和及时的通知，可以解决沟通层面的低效以及在传递过程当中信息损耗，从而提高沟通效率，而且避免沟通中的误解。在解决了当前透明化和及时通知的问题后，咱们须要进一步从如下两方面进行优化：

将通知进行分类以及优先级处理，下降通知带来的负面影响

经过信息内容优化，辅助业务进行问题的快速定位与排查

3.部署与流程流转过程须要人工参与：

对于持续发布流程来讲，有人工参与的地方势必会影响到其中的效率。因此咱们将部署和阶段流转拆分为两个方面看：

阶段流转：结合上述的阶段标准，经过程序来计算是否可以知足当前的质量状况是否能够进行阶段的流转，从而排除人为因素以及在阶段流转中的耗时，作到准确

部署：提取相应环境的配置信息，结合Docker化，将打包、部署、健康检查等一些列活动转换为机器的标准化执行，经过标准化来避免人为参与所形成的偏差或部署失败的问题

4.多机房正式发布验证人工监督：

目前在应用的正式发布流程中，因为涉及的机房和机器数量较多，业务上会进行分批验证，每发布完成一批机器，研发会通知QA进行这批机器中部分机器的抽检（部分自动化测试），在这其中也存在着效率上的问题。因此如何节约每次上线过程当中的人力损耗，也是在追求效能极致上须要解决的问题。

上述的每一个细节的问题，都在咱们通往快速业务价值交付的道路上设置了障碍。所以，为了达成更早（快）的交付业务价值的目标下，咱们必需要在交付效率、质量标准以及结果快速反馈这几方面的进行优化。

3.2 持续交付在高德的落地

基于上节拆分出来的4方面的问题，从工程角度来讲，因为迭代的排期，需求的分解与拆分须要进行长期的实践与规划，而且依赖于产、研、测、项乃至于其余部门的支撑，是一个须要进行逐步探索和调整的过程。因此咱们将着眼点放到后3方面的建设上，指望在短时间内先创建起快速发布的能力，清除在交付过程当中效率低下的点。

那么在解决效率问题的建设上，借助于集团提供的发布流程以及较好的部署能力，咱们将目前拆解为以下几个维度的抓手：

依托于集团的发布流程，在持续交付体系中创建与集团发布流程对应的标准化流程流起色制

创建服务端质量标准体系，拉通质量标准，去人工化

打通各环节的快速反馈机制，并对发布流程进行管控，让变动结果随时可见

下降发布过程当中的人为参与，让整个发布流程作到全程无人值守

经过下面持续交付流程图，咱们经过接入后的流程图中看一下以上4个抓手是如何串联起总体高德持续交付流程，而且这几项是如何在高德服务端交付流程中进行落地的。

创建标准化的流程流起色制

FY19高德服务端发生的线上问题中，其中因为变动或发布引起的问题占比约12%。经过这组数据，咱们指望可以经过创建一套完整的交付流转流程，实现对于变动的控制和管理，下降或避免此类问题的发生。

基于以上立论，咱们结合当前服务端交付特色，首先先确立以集团标准发布流程为试点，打通总体持续交付流程；其次，针对各应用中不一样的需求，例如：须要性能环境、覆盖率环境等，结合流水线配置，将整个持续交付的流程流转进行优化；最终沉淀为各服务的标准化流程流起色制。经过这种先僵化，后优化，再固化的方式，最终在服务端落地了多套标准的交付流程，避免了在交付环节上的遗漏，以及不规范的操做。

拉通并落地服务端质量体系标准

在高德现有的交付流程中，总体的质量保障手段大部分是在平常阶段进行的，在迭代交付的过程当中，各项质量保障手段执行了哪些，执行结果是什么，目前仍是经过QA人员进行人工问题收集与汇总，并断定阶段结果的经过与否。在这种状况下，会出现因为跟版人交替致使的质量项遗漏，以及质量标准难以把控的状况。

因此基于这几方面的问题，咱们但愿经过用机器把控替代原有的人工把控的方式，经过创建标准化的质量模板，来避免总体执行标准不透明，执行结果无沉淀的状况。而且，经过拉通标准，也进一步的规避掉了非重点服务质量检查点遗漏的状况。

经过与业务团队的沟通，咱们在第一阶段将现有服务端的质量保证手段进行拆分，提取了在不一样阶段中相对重要的12项质量项，经过机器监督替代原有的人为统计的方式。具体覆盖了以下几个维度：

打通各环节的快速反馈机制，并对发布流程进行管控，让变动结果随时可见

当创建起有效的质量体系后，在各阶段有了质量要求以及准入准出标准，解决了信息收集方面的问题，那么接下来咱们要思考的就是如何将收集上来的各类信息，有效的反馈到项目中的各个干系人，以便进行后续的决策支撑，而且当未达到阶段准出标准时，有效的控制项目的阶段流转。

咱们将问题拆解为两方面看，一是有效反馈、决策支撑，二是流程流转的管控。

从有效反馈、决策支撑方面看：

在接入持续交付以前，各业务线的针对不一样类型的自动化测试任务，大部分都有经过Jenkins或测试用例工程反馈结果的通知。可是此类反馈有一个致命的问题，就是经过单项反馈没法纵观全局，不足以支撑后续的决策。

在接入持续交付后，除了原有业务上的反馈机制，平台提供能针对当期版本的总体状态全览，能够经过平台随时观测到当前版本是否达到可发布的状态或者仍然存在哪些不足。将二者结合起来后，针对项目执行人仍然能够经过原有反馈机制了解到单点的质量结果；对于跟版人、一线、二线管理者这类须要纵观全局的角色来讲，经过质量大盘，能够有效且明确的知道当前版本与待发布状态的差距，并支撑后续决策以及调整关注的重点

从流程管控方面看：

在接入持续交付以前，可部署的产物不管是否通过阶段验证，均可人为的部署到任意环境下，虽然灵活性比较高，可是也存在必定的质量风险。

在设计持续交付流程时，对于灵活性以及规范性的取舍方面，咱们也与业务同窗进行了讨论。从全局看，为了不流程不规范引发漏测或其它线上事故，最终肯定在第一版时先保证流程流转的规范性，从而下降灵活部署上所带来质量上的风险。平台经过集团实验室插件与集团的部署发布系统打通，当阶段中存在质量项还没有达标的状况下，阻止发布流程进入到下一阶段（环节）。

当基础的持续交付流程落地后，为了知足业务上对灵活性的要求，目前咱们也在尝试经过自定义流水线来进行多环境的分发与部署，从而在保证主要阶段流转有管控的同时，增长部署的灵活性，以适应不一样的业务形态。

下降流程发布过程当中的人为参与，让整个流程作到全程无人值守

咱们知道，线上环境部署的复杂程度要远高于在平常和预发环境的部署。因为部分业务线，线上的机器数量众多，且分布在不一样机房，为了保证部署时的服务可用性，线上部署时会将上千台机器拆分为多批次进行部署。

在接入持续交付前，为了保证部署后服务的可用性以及对质量上的高标准要求，在每批次部署完成后，QA都须要针对当前批次进行全批次验证或抽测验证，当验证经过后，再进行下一批次的发布以及后续验证。虽然验证自己是经过自动化脚本进行验证，但因为机器和批次比较多，整个发布和验证流程会持续数小时，存在较大的效率问题。

在了解到业务上此效率瓶颈后，经过打通上下游系统，集团标准流程、集团发布系统以及原有业务的线上验证工程，针对不一样业务的发布场景，进行发布验证策略的配置化。经过感知部署时的消息，获取当批次部署的机器列表，依据各业务的验证策略配置进行自动化的验证。而且结合线上阶段的报警监控，当某批次发布验证出现问题后，系统能够第一时间定位到具体是哪一批次中的哪台机器发布出现问题，帮助业务进行部署问题的快速定位。

持续交付体系的业务架构

4. 落地效果

整个持续交付体系建设，目前在高德服务端落地已经有一段时间了，截止到目前为止：

业务线覆盖：整个持续交付体系已经覆盖了高德服务端大部分重点业务

各阶段质量项建设：12项

正式发布阶提效：50%~90%

在得到以上成果的同时，除了上述量化指标外，更有价值的是隐含在背后的研发、测试习惯上的变化。从研发、QA和项目主动发起的缩短项目周期，到QA对于质量项上提出更多的诉求等等，无一不感知到你们对于尽早且高质量的交付业务价值这件事情的重视。固然对于更早（快）的交付业务价值这个目标还有必定的差距，这个也是后续咱们与业务线须要共同解决的问题。

5. 持续交付的将来

有人将持续交付形容为在价值交付上的高速公路，持续交付的落地，标志着价值交付到用户的快速路已经创建完成。可是最终是否能作到更早（快）的交付业务价值，还取决于在这条快速路上行驶的车辆。

根据这个理论，咱们除了要保证这条高速公路上不出现坑洼的同时，还要兼顾车辆自己的能力，以及车辆的性能。所以，在车辆出发前，咱们更须要经过对车辆的车况进行检查，保证在高速路上行驶的车辆不会由于自身的缘由提不起速度。

5.1 车况检查

目前，已有的持续集成系统，仅可以保证车辆在这条路上是能开起来的，车况的检查都是在上了高速后才开始的（大部分的质量保证手段是部署到平常环境后才开始）。因此基于上面描述的指导方针，咱们须要尽早的作检查，而且须要作更全面的检查（质量保障手段左移）。

基于这个目标以及结合集团内其余BU的优秀实践，后续咱们但愿能经过代码门禁的手段，尽早落地这类全面的检查。若要将代码门禁落地，不管是对于工程效率团队亦或是业务研发与QA团队，都有着不小的挑战，咱们须要作到如下的转变：

• QA

质量保证的同期化能力建设

质量保证的稳定性与耗时优化

• RD

研发提交代码流程的改变

单元测试能力的建设

Code Review的常态化落地以及规范总结

• 能力支撑

代码覆盖率，业务场景覆盖率的支撑

代码合并的门禁管控能力

代码扫描结合CodeReview的总结的落地

当逐步完成以上任务的落地后，可以消除批量交付业务价值交付中相互等待的时间，而且也可以保证车辆在持续交付这条高速路上行驶得更快更稳定。

5.2 车辆性能提高

前面车辆检查能够说是在车辆上路以前的检查与保障，将质量保证手段左移到研发阶段。相对的，咱们但愿经过车辆性能提高的方法，在车辆上路后，可以让车辆行驶提速更快，拉高速度的上限。

• 纵向测试能力提高

精准回归：经过感知代码的变化，推导出代码变更所影响的Case，让质量保障更为精准且耗时更少

场景覆盖：结合线上流量回放，经过代码覆盖、场景覆盖进行查缺补漏，让质量保障更完整

问题定位：结合失败用例，快速的进行问题定位与反馈

同期化能力：结合云歌Case平台，经过接口定义进行测试代码与研发代码同期化编写能力的增强，以及下降Case编写和维护成本方面的探索

下降数据干扰：基于高频、隔离和用完即抛的理论实践，下降平常环境的数据干扰，让质量保证更有效

• 与线上数据挖掘结合

大数据分析：

利用线上日志分析，产出线上真实场景模型，下降压测平台语料准备耗时，场景筛选上作到精确、高效

大数据运用：

结合线上真实场景以及场景覆盖率，构造线下回归Case集，下降业务回归Case维护成本，提高Case有效率，而且可以快速定位问题

利用场景回放，以及记录回放中间产物，解决在单测时场景构造问题

随着持续交付快速通道的搭建完成，指望经过以持续交付体系为契机，在多个纵向维度进行深刻挖掘，并完善整个持续交付体系，最终在更早（快）的交付业务价值的前提下，可以有更高的质量以及更低的人工成本，保证市场竞争的先机，让高德在激烈的竞争中优点更为明显。