让持续交付流水线灵动起来-轻识

导读：本文主要介绍了百度持续交付流水线集团级方案。持续交付涵盖内容广泛，本文并不讨论广义的持续交付，而是聚焦在承载持续交付部分功能的流水线的上面的构建活动。围绕流水线构建，我们介绍了一站式流水线开放平台-百度双引擎构建生态、流水线效能提升利器-智能构建中台。

全文5479字，预计阅读时间11分钟。

一、百度构建发展史

1.1 什么是构建

软件的构建是软件生命周期中非常重要的环节，它贯穿于软件从开发到交付的整个过程中，构建过程直接影响交付给客户的软件的质量和效率。构建是一个不断收集源码、编译、测试并最终完成产品交付的过程。软件交付过程涉及组织、流程、技术等各个方面，本文中仅仅阐述技术相关的部分。

从技术的角度来看构建，构建并不只是将代码开发完编译好，构建涉及编译、流程管理、研发工具链以及这些平台工具的无缝集成等，通过技术上的方案支持流程自动化、敏捷开发。流水线则是软件交付过程（构建的大部分过程）的一种可视化呈现方式。

1.2 百度构建发展史

如图所示，在09年之前我们主要通过瀑布开发的模式来完成构建，传统的瀑布模式需要多角色协同，上下游强依赖，软件的交付在交付周期靠后阶段，技术人员经常遇到代码merge大灾难，且这个时期手工测试居多，很多事情依赖于人，效率极低。在随后的发展中，我们跟随业界的步伐，推行了敏捷开发模式，开始建立自动化测试工具，推行敏捷迭代机制，配合代码版本管理和持续集成降低代码merge所带来的灾难风险，在百度各个业务线维护自己的jenkins集群，以帮助本业务线完成持续集成。敏捷和持续集成的发展，在一定程度上解决了瀑布开发的问题，提升了开发测试的效率，保证了产品质量。

随着移动技术的发展，百度出现了越来越多的移动端产品，与以往搜索产品具有很大的差异，百度各个业务线诞生了大量移动端测试工具平台，如兼容性测试、隐私合规测试、异常测试、包版本管理等，为了助力公司移动业务的发展，从15年开始针对移动产品依托公司的移动测试能力我们推行了移动产品CI解决方案并推行至全公司。随着公司业务类型增多、技术的不断发展，系统复杂性变得越来越高，业务线越来越多，测试工具越来越多，我们发现快速完成软件构建方案，使得软件可以高质量、低成本、无风险的对外发布仍然存在很多问题。因此自17年后，我们着重于解决新的挑战和风险，先后建立了百度工程能力标准、百度的CICD双引擎生态（容器化与插件化），并开始向智能化测试迈进，本文也将着重介绍这个阶段我们的重点工作。

1.3 新的问题

前一章节我们阐述了百度构建发展史，实际上在17年之后我们遇到了在百度内部特有的新的问题和挑战。随着多年的沉淀和发展，百度内部不同业务线发展出了多种多样优秀的开发测试平台，这些平台着重服务自身产品线，同时在富余时间里支持其他外部产品线的需求。在这个时间里，各个业务线维护着自己的jenkins集群，以满足本业务线的持续集成需求。

这样的状态存在如下一些问题：

业务上：

新产品形速度态、新技术应用、复杂架构，对构建有新的要求
迭代要求越来越高，对构建效率要求同步提高
不同的业务类型、不同技术栈对构建要求不尽相同

技术上：

构建量增加，构建稳定性、构建成功率下降
构建链路变长，各类异常的人工成本
资源紧缺状态下提高构建效率
工具平台散乱，同质平台过多，无法统一管理优化
工具平台散乱带来版本不一致、管理混乱，稳定性也受到影响

为解决这些问题，开始探索一站式的流水线开放平台，并针对一些问题进行统一的治理管理。

二、百度双引擎生态方案

如图，百度搭建了双引擎的构建生态，生态上承接业务线各类构建需求，下对接各类专业开发、测试、运维工具，并形成了一套标准的工程能力及治理规范，对工具进行稳定性可靠性治理。该生态存在两类构建引擎，一类是标准引擎，标准的工具/平台能够对接进入流水线平台中被业务使用，同时该类引擎接受平台的管理治理，另一类是非标准引擎，它解决业务在组件自己的流水线时一些针对业务本身的非标准构建任务，如业务自有的工具、业务用来做报告组装的任务等。接下来我们详细阐述双引擎生态中的标准规范、标准引擎-插件中心，非标准引擎-CI容器化。

2.1 工程能力标准

为引导业务做好自身的构建交付，规范化工具平台，百度成立了DevOps-TOC，制定了一套工程能力标准。该标准包含工程能力分类标准工程能力度量标准，覆盖产品类型包括SERVER类、SDK/APP类、AI类、FRONTEND，覆盖软件研发交付的需求/架构设计/开发/测试/运维/上线全交付过程，构建双引擎生态依托工程能力标准对引擎工具进行分类管理及治理。

2.2 标准构建引擎—插件中心

以往业务线搭建自己的流水线构建方案的方式如图所示，业务线自行维护自己的持续交付平台，同时通过各种渠道从外部引入一些工具能力，外部工具往往是针对自身业务定制的，长期必然存在外部工具无法满足本身业务需求的情况，此时矛盾凸显，外部平台无法适配业务的需求，业务因工具能力不足影响交付。

为了解决这些矛盾，我们建立了标准构建引擎，插件中心。插件中心首先要统一交付平台降低业务自运维交付平台的成本，在此基础上通过开放平台的形式打通业务、工具、交付平台三方，在开放平台上工具可以注册自己的服务，该服务注册完成即可在交付平台中直接被业务使用，业务可按需选择自己需要的工具，同时通过平台的渠道反馈工具问题，背后统一由DevOps-TOC组织来规范工具的对接标准、稳定性治理标准等。

2.2.1 快速获取标准插件能力

从业务线的角度，业务线更关注如何快速的获取标准插件的能力并低成本的使用。从工具的角度，更关注如何可以快速的对接到插件生态中来并可以快速迭代。如下是我们的具体解决方案，在该方案中，针对工具的快速接入，我们设计了基于标准接口的插件化框架，将插件的运行标准化为调起、轮询/回调、取消三类接口，工具方按照标准接口规范开发接口注册对接即可，针对业务的低成本使用，我们将业务的使用场景抽象化为动态参数，业务在系统中能够配置系统提供的全局参数(如环境变量)、插件参数（插件提供给业务可配置的参数）、业务参数（业务在持续交付平台上可自定义自己的定制参数），这些参数组装为业务的定制场景在插件化平台中运行。

2.2.2 获取稳定优质的插件

插件中心开放平台解决了业务及工具快速接入的问题，但是工具对于业务的稳定性可用性问题并没有真正的解决。工具插件的稳定性可用性问题，单靠技术无法解决，必须引入组织的力量，通过DevOps-TOC建立了一套插件对接审核、插件治理的机制，在这套机制下，插件的接入需要经过TOC的审核，插件的可用范围与插件的能力支撑度强相关且需要TOC认证。

认证机制解决了插件对接时的稳定性、可靠性、可持续性等问题，在插件接入后在平台持续运行过程中我们仍然需要关注插件的质量，因此TOC也建立了一套插件评估指标体系，在插件进入插件中心生态后，会被平台监测是否健康是否符合TOC认证标准，平台提供丰富的插件运行数据支撑插件对自身运行情况进行评估改进。

2.3 非标准构建引擎—CI容器化

标准插件引擎插件中心并不能覆盖DevOps构建的长尾流量，同时在资源收紧的情况下，业务线的资源被收拢从静态资源变为动态资源，这些都超出了业务线可解决的范围，因此非标准构建引擎-CI容器化应运而生，用来支撑非标准任务的执行管理。整体流程如下图所示。

长尾流量的特点：

时间短：54%的任务执行小于30秒，这就要求：

任务执行稳定性必须很高
不能有长时间的任务排队

稳定性低：整体稳定性不足95%

1）slave机器上的软件环境手工运维，标准缺失，环境问题导致任务
失败率高达5%
2）宿主机上直接执行任务，任务间会相互影响

资源利用率低：长尾流量大部分是绑定slave进行，这样会造成极大浪费。

基于此，我们提出基于K8S+docker动态集群构建方案，该方案有以下特点：

即申请即释放的docker容器执行任务，主要优点有：

速度快：docker容器构建速度快，2~3秒就可以创建出新容器；
稳定性好：容器隔离性好，软件环境通过镜像构建完成，标准统一；
排队少：资源整体配置管理，动态获取容器，用完即释放；

稳定性专项优化：主要的工作有，容器缓存系统构建、灾备系统、跨地域
多机房资源池调度等；
效率专项优化：主要的工作有，容器缓存系统构建、镜像预分发、任务高
并发执行等；

基于插件化+容器化双引擎的构建方案，分别承担了80%，20%的流量，使得构建领域的软件标准化、稳定性、资源利用率、工具/平台复用程度等方面都得到极大优化，更难能可贵的是标准化的构建，带来大量的结构化的构建数据，为下一步的智能构建奠定了基础。

三、智能构建

3.1 智能构建的产生

在业务线能过构建双引擎生态快速搭建自己的流水线后，随着业务的快速迭代，对构建效能提出了更高的要求，传统的流水线存在：

1.执行流程固定，存在一些无效执行，如在执行中不能根据执行的历史信息进行执行决策，导致冗余执行，不能站在风险的角度进行选择性的构建也导致了冗余；

2.执行资源的浪费，如在执行过程中同类型的任务反复执行，不考虑业务优先级进行动态调度执行，导致有限资源未被高效利用；

3.构建中人力的浪费，如构建过程中任务失败，阻塞执行时，需要人工介入进行分析定位排查，导致人力的消耗等。

在经过大量的调研分析后，我们发现，流水线编排系统以及工具平台都有动态构建的需求，细分起来应用方期望在构建前进行任务的跳过或前置的分析（如代码分析等），在任务触发后能够根据构建信息动态的觉得当前的构建取消、复用结果或动态修改一些运行中参数，在任务结束之后期望可以对任务做一些自动定位、标注，对非预期波动导致的失败期望可以重试自动愈合。无论应用方希望在哪些环节插入动态构建，最终目标都落实在效能上，通过动态的调整使得整体构建效率提升和节省资源的目标，通过动态的插入一些任务减少构建链路中人工值守的成本。

3.2 按需动态执行的智能构建

从分析到的需求到技术实现上来，有三个关键的点，一是中台如何去支撑所有的动态构建场景，二是如何去确保可以有更多的策略人才共同开发，构建良好的策略生态；三是构建中台直接干预流水线构建任务，如何保证构建中台稳定性不影响CI稳定性。

在阐述方案前，我们首先定义一个概念：策略。我们将在流水线中需要动态插入的各种操作抽象为策略，既给予构建过程数据、结果数据等，通过一定的模型算法，对构建流程、构建任务执行及构建结果进行干预的行为，即为策略。

不难分析出策略的执行时机是在构建前、任务构建中及任务构建后，策略对任务的影响可以分为分析类策略及决策类策略（分析类策略不影响任务状态，决策类策略影响任务状态），作用范围策略需要可以作用于当前任务、同类型任务、整个流水线。从实际使用上抽象，策略在实际的使用中并非孤立使用的，策略直接存在依赖关系、同一个任务可以有多个策略，因此中台完成策略的依赖链路计算、调起执行、结果处理等，如下图所示：

中台通过抽象动态场景使得业务的策略可以动态的影响流水线，在此基础上中台仍然需要进一步考虑如何使得策略接入的成本最低，使得策略贡献者可以最低门槛最小成本的完成策略。中台通过托管了策略的接入管理、策略链路计算及调起回调处理等使得策略无需关注外围，同时在策略接入&开发&调试观察成本上，中台通过对接策略平台使得策略开发降级为一个脚本的开发，通过细分定义策略二级类型使得策略开发者能够聚焦策略内容开发，通过提供效果及调试服务使得策略开发者无需为调试及效果观察浪费精力。

3.3 长尾构建后闭环

智能构建使得业务可以注入自己的策略，将流水线的固有执行变成按需动态执行,解决了动态执行的问题，但构建中人工定位排查的成本仍然未得到很好的解决，在构建过程中人工定位排查往往在构建任务结束后，排查人员收集大量的构建运行数据分析定位问题，并予以解决。

从大的层面上问题可以分为三类，构建平台问题、业务代码问题、工具运行问题（包含工具依赖的第三方问题），这几类问题的归属方、解决方均不同，从问题发现到定位到驱动解决往往链路过长，解决效果不好。中台在构建后提供了问题闭环服务，支持用户定制自己的问题闭环流程，插入问题分析、标注、自愈的策略，整体可以自动运行下发，极大提升了构建后的问题上报效率。

3.4 智能构建业务交互逻辑

最后，一张图说明一下智能构建的业务交互逻辑，构建中台由流水线触发，中台提前进行前置的特征分析计算，用于后续任务调度决策，任务调度决策根据业务的策略决策当前任务的执行，在任务执行结束后，中台触发风险分析计算，并对构建过程中的问题进行分析分类上报处理。

四、总结

回顾一下，这篇文章整体阐述了百度的智能构建发展史，我们先整体阐述了百度的构建发展阶段，并针对17年之后百度在交付构建上的问题进行了深入的分析探讨，解释说明了百度的构建双引擎生态。在有了双引擎生态之后，进一步利用数据来进行智能的决策运行，我们阐述了百度的智能构建中台的搭建。

当前该套方案已应用于百度各大业务线智能流水线中，系统中含有80多个能力插件，智能构建覆盖了近2000代码库，数百构建策略，日均构建数万次，为业务效能提升提供了简单易用的工程方案。

end