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

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有效率，而且可以大概快速定位题目
使用场景回放，以及纪录回放中央产物，办理在单测时场景构造题目
随着连续交付快速通道的搭建完成，期望通过以连续交付体系为契机，在多个纵向维度举行深入发掘，并完善整个连续交付体系，终极在更早（快）的交付业务代价的条件下，可以大概有更高的质量以及更低的人工资本，包管市场竞争的先机，让高德在剧烈的竞争中上风更为显着。