如何借助 Jenkins 实现 DevOps 工具链

彭小阳

作者简介：

刘长城，2007年加入华为并在华为工作至今，一直从事华为研发工具相关的设计开发工作，参与打造华为研发全流程工具链，包括从需求管理、架构设计、开发测试、测试工厂、环境管理、Android手机测试、持续交付流水线等研发各环节的工具支撑。

前言：

今天我分享的题目是基于Jenkins的DevOps工具链。之前很多老师也都分享了在DevOps里边要用到的工具非常多，有这么多工具，怎么把这些工具串起来，把公司内不管是开发、测试或者运维，大家在同一个平台里边去工作，能够推动整个DevOps的流程更快的流转下来。
今天我演讲的顺序就分几部分：一，华为研发模式演进，华为从传统的流程慢慢转化成敏捷，到CD，到DevOps整个流程工具的演化过程我都参与了。工具的研发也都参与在里边。二，DevOps工具链相关的概念，在华为内部为什么选用Jenkins作为我们的DevOps工具链的核心。最后，华为公司在用Jenkins的时候碰到的问题，我们是怎么解决的。

一、华为研发模式演进

先简单介绍一下华为，华为现在研发人员就有超过8万人，公司去年投入746亿人民币，在中国应该算是数一数二的，大家都知道没有研发对于一个企业来说就没有未来，也是在为未来投资。

简单的列了一下在华为研发模式演化的过程，华为是在1987年成立的，最开始没有什么研发的东西，到90年代开始做交换机这些东西。

在后面做的东西越来越多，到现在没有人知道华为做了多少东西。90年代那个时候的研发是属于八路军游击队的年代，没有什么工具可言。
那个时候抓到什么就是什么，有一个故事，华为公司内部有一个交换机，同时支撑几千，上万个人或者几百万个人打电话，碰到这种场景的时候没人知道怎么测，一个交换机怎么能扛住这么多人的压力，那个时候完全没有自动化的概念。我听之前的老同事说他们就靠人，每个人面前摆很多电话疯狂的打。
到了2000年以后学习了国外的经验，像这种工具国外有非常多，也慢慢的引进来了。只是说压测工具非常贵，一个机器上千万，当时公司觉得怎么这么贵，但是也必须买，买的话还不如我们自己投入，自己开发。当时就成立了工具部来做压测工具，专门测华为自己的工具，那个时候我们部门开始成立了，也开始慢慢把华为公司内部需要用到的一些东西自己慢慢的研发出来了。
我是07年加入华为的，因为前面我们也做了很多东西，包括测试的管理工具。我们公司比较大，测试人员上千，测试用例的话会上亿条数据。这就需要一个非常大的平台管理，那个时候很多部门就开始做大的测试用例管理平台。后来就开始做蝴蝶7X24小时的测试自动化平台，叫做测试自动化工厂。自动化用例要有环境，要有脚本的平台，还要有调度。当时自动化测试工厂也投入了很多人，做了很多事情，刚开始每个团队自己在管理，那些配置都很不一样。如果要上平台的话，一上就跑不起来了。
当时就说先做环境的管理服务，我们需要制定执行规范，要把标准化做起来。后来我们做了一个加速用例平台，这样的话可以把所有的资源都用起来，可以把整个执行的过程非常快的做起来，原来几天跑完，现在一个小时就跑完。08年的时候公司在做敏捷转型，我们就开始做CI，CI里边主要聚焦开发阶段，怎么支撑开发，包括单一测试用例怎么写，包括静态检查工具也引入了一些业界的工具来做。也需要慢慢朝着自动化的过程做。
到了2013年CD的概念比较流行，我们开始做CD持续交互平台，那边有一个图是当时持续交互平台，做的是一个可视化的看板。上面会有需求的进度，完成的百分比，下面是各种流水线的状态，哪个团队的流水线是否是绿色的，或者是项目组的哪个组件跑挂了，上面就会标红。这里做的是分层分级的持续交互平台。
到2013年DevOps这个概念也慢慢开始活起来了，我们团队也开始负责做DevOps的转型所需要工具的设计和开发。这里边包括服务化、容器、运维、发布反馈里边所有的东西都慢慢做进去了。

从华为的经验软件研发流程，最开始我们会做CI，有时候也会做CD，当时做的是持续交付。因为很多产品不是互联网的模式，不是自己自运维的。一个手机是交互给客户的，这就很难说交互给客户之后再来做测试，测试反馈回来再把手机拿回来，再重新升级，然后再给客户。当时很多概念里边把版本很快的交互出来。后面内部也有很多产品在做云化的改造，内部也开始有一些对外运营的产品，华为云整个都在慢慢朝DevOps转型。

二、DevOps工具链

接下来是DevOps工具链。我们先看一下整个DevOps关键的实践，这里分了几层，这个概念很多人都提到过。对于一个团队要做DevOps的话，比较关键的在于最下面这些，一个是团队协作、特性设计跟自动化能力，架构和基础设施。一个产品如果架构上，类似于一个汽车不是服务化或者架构不是很隔离的，这就很难做到DevOps的交付了。

2.1 DevOps关键实践

首先对于你的应用来说内部的组件起码能做到相互隔离，能够自己跑流水线，自己去部署，你的升级不会影响到其他的模块。在架构上有很大的要求和考验。
再往上这里会有很多名词，可能有些人比较熟悉，精益开发和特性看板，这是从特性设计这一层要求的。如果说要做DevOps，核心理念我们的特性是一个很小的模式交互，我们一个汽车不可能先交互一个文字给你，你就能跑起来了，像这种模式要说做汽车可以按照DevOps的模式去做，不可能光买一个轮子，等着他过段时间再把发动机交互给你。产品在特性设计上会有很多要求。
上面构建、部署和自动化，对于DevOps里边最核心的能力就是自动化能力，包括验证、构建、部署，开发人员提交了一行代码以后，包就自动出来了，包自动部署到测试验证环境上面，测试验证自动跑完，跑完了之后你的报告给你，验证结果就出来了，这个版本是否验证OK，是否能够自动的发布到下一步的环境上去。非常考验自动化能力。
这里边还有其他的实践，你在升级你的产品的时候肯定要保证我的服务业务不中断，不可能你要升级的时候别人不要用，像这种的话一个产品可能就失败了。
基础设施即代码，很多业界也强调的比较多。我们的环境是否能够通过非常快的，通过一些脚本有一些环境的描述，通过环境的配置工具一下子就能下下去，测试和生产环境就出来了，不需要人做很多事情。

2.2 DevOps CALMS模型

DevOps有文化、自动化，精益度量和分享，DevOps画了外面的大框，中国是一个文化。以前老的交互模式开发是开发，测试是测试，运维是运维，运维生产环境出了问题可能就要找开发定位，半天很难拉到开发的人过来定位，因为运维对产品也不是很了解，类似于部门墙也比较大。
DevOps的文化意思就是说开发、测试和运维就不要区分的太明显，开发肯定也要知道运维，最终你的产品开发出来之后部署到环境里边会是什么样，或者是怎么部署的，出了问题怎么快速的定位出来。
我们的构建部署和发布和验证能够快速的完成，确实也考验很多团队的能力。精益的核心价值就在于我们能够在交互的时候交互出最有价值的特性，有时候一个产品开发出来最后发现80%的功能都是没人用的，用户要用的只是其中的20%功能，很多工作量就浪费了。对精益来说能够告诉你，能够让你快速的发现哪些特性是你的用户需要的。
最下面讲到度量，有监控、用户分析，有很多指标帮助你定位你产品的价值，交互出来的特性哪些客户经常点击。监控是能够发现你的系统出了问题，你知道你的问题在哪里，告警告诉你或者发一个短信，收到一条短信告诉你某个进程都OK，你需要去处理。

2.3 DevOps工具链全景图

刚才讲了那么多，在华为我们做的工具链，这是DevOps工具链全景图。跟早上他们这边讲的也差不多，内容也差不多，我们也会有一个需求看板，下面会有一个IDE，有了需求肯定需要有一个IDE来写代码。对于我们来说一个团队的IDE环境都是类似的，基本的配置大家都差不多。在华为来说专门有一个团队在做IDE的事情，在页面一点直接在IDE环境里边写代码。

2.4 我们需要什么样的DevOps工具链

开发的代码，测试用例，部署的脚本，对于环境的定义，不管是开发和测试，打造了我们自己的托管服务。构建服务是在Jenkins之上做了华为的改造，把它服务化了。内部团队非常多，每个团队都会自己管自己的Jenkins Master。我们这边做的是把Jenkins

Master服务化，对于你这个小团队来说不需要去维护你的Jenkins，如果你有一些需求直接给构建服务就可以了。你用的时候就直接在页面上点一下，页面上点一下构建任务就执行了。

三、Why And How Jenkins

3.1 Pipeline as Code with jenkinsfile

我们在Jenkins上做了一个构建服务，构建出来的都需要一个仓库服务来存构建出来的东西。构建完了之后可能需要去部署，去验证，我们用的Jenkins Pipelines时间比较早，2014年就开始用，那个时候Jenkins Pipelines还没有官方发布，那个时候是在Jenkins一点几的版本上用的Jenkins Pipelines插件。那个时候Jenkins Pipelines的工人相对比较弱，我们也做了华为内部自己的改造。
![12.png-74.4kB][13]
下面就跟今天上午讲的差不多，你可能会部署到各种环境上去验证，环境上可能会有很多监控的工具，像普罗米修斯，把操作数据写到这里边。现在是因为集群版本要收费了，接下来后面再改掉它。
这个图是可视化页面，最右边是我们自己用户运营数据图。这是华为工具链的前景，核心还是通过Jenkins去跑我们的构建，还有跑我们的流水线，把整个流程串起来。为什么会选择Jenkins呢？因为Jenkins社区是很庞大的，提供了超过1100家各式各样的插件去与各种工具进行对接，实际上社群还是非常强大的。我们今天上午也看到现在在CACD领域Jenkins的占有率达到了百分之八十多。
这里稍微讲一下我们为什么会选择Jenkins来做我们的流水线？如果大家对Jenkins比较熟悉的话这一张就可以忽略掉了，我这里列了几个选项：第一，非常灵活。如果你要用Jenkins的话，原来没用过，现在要用的话只需要在你的库里边增加一个Jenkinsfile，右边的文件来描述流水线的步骤，右边是官方的视图。

第二个是编排能力，以前华为内部也用到一些商用的工具，通过一些脚本进行编排。如果你是一个语言的话，要编排你的流程是非常灵活和强大的。你要做循环或者做并发，或者要做超时的控制这个就非常灵活，非常好做。现在流水线的执行跟原来构建的执行是不一样的，它可以不占用你的资源，不需要去指定，流水线都是在Master上执行的。
开始我也问了Sam一个问题，Master上可以执行到百万的流水线。问题真正执行了一百万流水线的时候基本上Master也就挂了，没法获取到流水线的信息了。没有控制Master上到底能执行多少，如果不停地往Jenkins Master发执行的话就不停地执行，执行的时候都已经很慢了。我后面会讲我们华为是怎么解决这个问题的，困难就不用讲了，插件非常强。

3.2 Jenkins常用Steps

这边是官方提供出来的一些能力，在用Jenkins Pipelines的时候很多东西已经帮你选好了，包括怎么执行脚本，怎么执行Bat，怎么去做git下载，怎么读写文件，它都帮你写好。如果说要做一些用户的交互，它业提供了Input的step，帮你做等待确认的问题。

3.3 扩展Pipeline steps

要扩展这个Jenkins的话也很方便，你只需要扩展出一些step，你要写你在step到底需要执行什么内容，要写你自己的代码。它也分几种，你是同步把你的代码执行下去，还是异步执行下去。因为很多步骤是比较耗时的，流水线同步一直往下走，流水线就在这里。

我们现在做的，一个步骤调我的部署服务，让部署服务去做部署，这个部署很耗时，部署要十几分钟，不可能流水线一直等它吧。这里我们要把这个状态获取到。

3.4 Jenkins Pipeline的可视化

我们做流水线比较早，我们实际上是自己做了一个可视化的页面，右下角是华为自己做了一个基于Jenkins的可视化界面，如果你们要看的话可以上华为软件开发官网，软件开发云是免费使用的。我们比它的能力要强一些，我们这些步骤都是直接拖拽的，这个图就画出来了。用户不需要真正写那些脚本，对我们的用户来说只需要在流水线的配置页面上拖两下这个流水线就配出来了，这个流水线也支持嵌套，这个东西还不支持嵌套。

四、华为jenkins企业级应用

4.1企业级Jenkins要解决的问题

我构建跑完了之后，代码检查会做各种各样的静态检查。我们会配一些门禁，这些结果达不到门禁的时候流水线不往下滑。前面讲了很多DevOps的概念，下面是讲我们在用Jenkins的时候解决了哪些问题。
因为现在Jenkins的需求就是要提供一个随时可用、可靠，而且是高可用的Jenkins服务？一个用户过来随便点一下整个Jenkins服务就可以用了，而不需要去安装，去做很多配置。同时它也要能够支撑起10万级以上的用户使用。而且要保证用户在这上面的数据安全、合理，因为可能很多项目组不想我的代码被其他人看到.
我的代码在Jenkins上构建的时候打出来的包只能有权限的人能看到，其他人是不能看的。为了降低用户使用成本也需要提供标准化的构建环境，或者构建一个安卓的APP，你可能只把代码传下来了，一下子就变成了这样。

4.2基于Jenkins流水线架构

这是流水线的架构，对于我们来说上面有一个业务的服务层，对于用户来说可能都不知道任务是跑在Jenkins上的，只是因为我们把业务重新设计了，而且重新开发了。因为最早我们选Jenkins的时候，领导觉得这个页面感觉跟其他的工具风格不一致，样式也很普通，我们要再推的话肯定也要做一些修改。
上面是业务服务是单独开发的，Jenkins完全在下面，中间我们加了一个调度。我来了请求，可以基于下面这些Jenkins的负载情况，比如说下面有10个Jenkins，其中有5个执行的任务比较多，第6个比较空闲，我这个任务就会分到第6个上面。同时对这些所有任务的状态都会监控。

4.3CDDL定义说明

为了做这个平台我们也定义了一个语言，叫CDDL，华为内部定义的就是流程描述的语言，因为它的格式就是标准的Jenkins。前面我也提到有一些Gearman方案，可能我们有Jenkins Master，但是Jenkins需要做到资源的共享，原来这个项目有10个，那个项目有10个，每个项目各用各的。现在通过这种模式可以形成20个资源池，然后按需两个项目组共用。这是一种方案。

4.4 Slave共享方案

这里做了一个总结，我们在Jenkins上关键的实践，对于多Master均衡负载，Master对Slave获取效率。刚才我讲过我的Master对Slave是共享的，我怎么能够比较快的获取到一个执行资源，然后把它执行下去。
Master升级的时候我怎么做到任务不中断，我们说我们是一个DevOps平台，但是实际上在我的DevOps流水线里边，流水线自己升级的时候我发现其他人就不能用了。我自己都没有做到DevOps，这是对我们自己的要求，Master升级的时候整个平台的任务还是能够继续执行的。其他是监控和日志服务的实践。
这就是我今天的分享。