流水线驱动 CD / DevOps

毕宏飞

前言

张乐：大家知道 DevOps 这两年提的特别多，非常火，我们希望从社区的角度 DevOps 不仅仅是概念的纬度，更关键是一个可以落地实施的纬度。我们觉得流水线是 DevOps 里面非常好的落地抓手和落地方式。

今天的分享，我们有两部分内容：

第一部分就是我们要做一个 DevOps 和持续交付流水线的现状调查报告。前一阵高效运维社区和 DevOps 时代社区，做的现状调查。世界范围内 Jenkins 已经非常火了，国内 Jenkins 持续交付方面做的怎么样？大家水平是什么样的？有什么样的趋势？
第二部分是如何实现端到端的流水线，我们会给大家展示相关的解决方案。

一、持续交付的现状

在8月18日的会场，我发布了一个 DevOps 道法术器的内容架构。

在道的层次如何快速交付价值，法的层次如何打通敏捷开发高效运维，术的层次如何应用最佳实践，器就是如何落地实践。今天我们谈“术、器”的部分，大家都知道 Pipeline ，KK也做了很好的介绍。 Pipeline 是一个流水线，希望把软件、版本控制库交付到用户手中的过程。

DevOps 社区做了一个报告，很多专家帮我们做了分析。

我们的目标有下面几个方面：

• 业界的现状，大家都在谈 Jenkins ，用的深度是什么样的，我们要做一个调研和分析；
• 发展的趋势，希望可以告诉大家哪些主流方法、时间和工具已经被深入应用了，我们从业者的角度是不是有参考价值；
• 未来的方向，未来 Jenkins 也好、 Pipeline 也好、流水线、 DevOps 应该演进到什么样的位置；
• 改进的反馈，听听大家的看法，比如说对 Jenkins 本身的想法需求，也会反馈给 Jenkins 团队。

1.1概述

概述的数据来讲，我们调研了国内比较大的范围。

跟我们IT从业者分布是比较接近的，北京、上海、广东这些地区的受访用户非常多。这里看到一个现象，不仅仅是互联网公司，更多的软件公司、金融行业、电信行业，各行各业都在不断的实践 DevOps 、流水线。

从上面这个比例可以看出来， DevOps 实践已经不仅仅局限于互联网公司，越来越多的公司也在实现。公司规模也是一样，超过1000人以上的公司占43%，100到500人的公司占30%多的比例。不管是小公司还是中大规模的公司都开始有意识的投入 DevOps 和持续交付流水线的建设。

我们从统计结果来看65%的受访者可以实现每周一次以上部署的行为。随着我们业务的压力越来越大，移动互联网、互联网的时代里面，业务迫使我们IT不断的迭代，用敏捷、 DevOps 的方式交付我们的软件，交付频率的压力是非常高的。但我们要考虑一个问题，不仅仅是快速交付就可以，在要求快速的情况下、保证质量的交付，不能单纯因为快速牺牲质量。所以我们做了一个交叉的分析，对于每天发布多次和每个月甚至按季度发布的公司，部署的成功率有什么差别。

这里有一个很有意思的现象，我们发现部署频率越高的公司，实际上对于部署的成功率还是比较高的。但是对于那种相对保守的，按月甚至按季度部署的公司，他部署的成功率其实是低一些。所以就印证了一个说法，我们的部署频率实际是和我们的部署成功率是正相关的。就像业界大使马丁福勒说过一句话“如果这个事情让你觉得很痛苦，那你频繁的做，频繁的演练，极早的发现问题，缩短你的反馈循环”。

流水线我们说到不管是 Jenkins 还是持续交付都是非常关键核心的部分。在我们的受访者里面，已经有64%的受访者表示已经采用了持续交付相关的实践，如下左边的饼图。

右边的图对于采用流水线的交付做了更深的调查，64.4%的受访者需要手工触发 Jenkins 的job，34%是定时触发，只有31.3%是每次代码提交都触发。

1.2流水线实践

下面一个点要看对于流水线阶段有很多具体的实践应用。我们分三个阶段：一个是提交阶段，一个是测试验证阶段，一个是部署发布阶段。

这里面列出一些，像红色的部分就是我们认为大家已经在填报问卷当中做的比较多的实践。绿色的部分是大家做的不太好的，或者是比较小的部分。代码提交阶段如自动化编译、打包、分支开发这些是比较成熟了。对于自动化测试、自动化单元测试，这些我们认为优秀的实现并没有大范围的应用。测试的角度来讲，我们自动化的部署，包的推送、自动化接口测试做的比较完善，但对于探索性测试和非能的测试，大家做的不是很充分。部署和发布阶段也是一样，类生产环境的验证、部署、自动化生成、维护环境这是大家比较普遍接受的实践了，但对于灰度发布和自动化回归测试不是很充分。

这个图KK看了会比较高兴，在国内调查情况是这样的，我们交付流水线工具在 Jenkins 这块已经达到86%的比例了，其实已经远远超过其他的工具。而且我们可以很欣慰的看到87%的用户已经跳转到2.0以上的版本，采用新的 Jenkins 功能，所以我们国内用户都在与时俱进。

对于新特性应用成熟度我们也做了统计，中间的部分是比较高，我们国内可能需要一定周期消化这些功能，把这些功能够真正试点、实验和落地。

1.3 工具的生命周期

我们下面快速看一下整个生命周期工具的情况。


首先是需求管理工具，从调查统计来讲， JIRA 和 Redmine 是比较高的。代码管理工具 Gitlab 、SVN、 github 都有了应用。对于代码扫描工具有很多，包括PMD、 checkstyle 都被大家用的比较多。制品管理工具有 harbor 和 nexus ，随着容器化成熟， harbor 已经占了21%的使用率。构建工具来讲， maven 占了73.8%，是非常多庞大的用户群体了，还有相关其他的工具。测试里面也有很多工具，我们要去应用，这里面就不太详细展开了。

但我们也发现，刚才是比较主流的工具，在整个 DevOps 持续交互过程中，还有很多关键的组成部分。

比如说分布式管理控制中心，我们在容器化里面如何动态管理应用功能配置，如何做到功能开关等等的东西，其实并没有被大家广泛的接受。大家可以看到这里面的进度条是比较短的，只有百分之十几甚至个位数的人才使用相关实践。对于数据变更管理工具和安全管理工具大家没有太多的接入，这个未来是我们可以提升的的点。安全性、合规性也是我们对于快速交付系统来讲非常关键的重要组成部分。

刚才大家看的是工具，我们还要关注另外一个关键点，这么好的方法和工具有没有跟流水线结合？我们经常举例子，我们有一台电脑一台总线，有CPU、硬盘、内存，如果我的CPU、硬盘、内存很快，但没有连到一个总线上，这样就不可能端到端的交付你的价值。

所以我们做了一个调研，这个图可以看出来，这个数字不是特别高，大多数只有百分之十几到百分之二十可以很好的把工具和实践跟我们流水线衔接，更多的情况是这些工具自扫门前雪，各自为政。对于 Jenkins 和持续交付流水线来讲，集成是永恒的话题，也是我们快速交付价值关键的一部分。

1.4 jenkins 的问题及改进建议

对于 Jenkins 来讲，从用户角度我们收集了一些问题。

开源工具的集成复杂度比较高，企业级的功能需要完善，还包括一些学习成本的问题，这些都是大家真实的反馈，我们也会原封不动的反馈给 Jenkins 的团队。大家对 Jenkins 来讲，还有很多期望，包括要完善官方的文档，希望URL更快，这些都是 Jenkins 未来主要的目标。

我们得到的结论是对业务交付频率确实有很高的要求，所以65%的受访者已经实现了每周一次的部署频率，对于这么高的部署频率，就要求我们必须要用自动化的手段、流水线的手段帮助我们达到这样的水平。部署频率和部署的成功率是正相关的，所以我们可以用技术手段来帮助我们又快又高质量的价值流动和软件的交付。64%的受访者已经在采用了持续交付流水线，其中86%都在使用 Jenkins ，所以大家今天来到 Jenkins 现场都是很主流的用户。对于各阶段的工具和流水线集成比例比较低的，有的阶段自动化触发率只有31%，这是表象。表象的背后我们还希望做一个更深层次的分析，也就是说为什么我们有很多集成的困难，某些工具没有使用起来。我们认为是冰山理论一样，其实我们有很多分析。

• 第一点是流水线集成很困难，尤其是各个开源工具和各个主流工具，每个工具有自己的职责、自己的功能要求、自己的设计，并不是生来就能集成的。我们有很多技术方案，很多技术专家，应该把我们集成的事情做的更好。要形成一个端到端的部署流水线，让各个工具真正能够集成和相互联通；
• 第二个是自动化触发比率低，我经常表达一个观点，仅有工具是很难把持续交付和 DevOps 落地的，工具要基于很好的方法、时间的引导，可以把很敏捷的工具用成很传统的方式，所以我们工具要结合我们方法和实践一起整合和推进才是更好的方式；
• 第三个是优秀实践应用不全，希望大家慢慢的从前到后推进，包括我们灰度发布的过程，以及分布式管理控制中心。从我们社区的角度、从提供方案的角度帮助大家慢慢把这块的能力做一个不聚合提升。

二、如何实现端到端的流水线

接下来分享的是端到端持续交付流水线V2.0的介绍和演示，我们4月份发了1.0的版本，这几个月的时间我们有什么新的变化和提升呢？下面由我们两位同事景韵和石雪峰，我们一起说一段群口相声。第一个我们要询问景韵，我们1.0版本的流水线到今天2.0版本经历了什么，有哪些新的特性跟大家介绍一下。

景韵：今年4月21日我们在深圳发布了流水线1.0版本，但跟社区朋友交流过程中发现企业存在更复杂的应用场景，所以我们把流水线2.0持续的迭代。

我们要解决这主要的三个问题：

第一个是要有更真实的企业应用场景，包括微服务的架构、端到端的流程，从需求开始到发布上线，包括我们监控；
第二个是整合更主流的工具，包括我们友好的商业级工具，包括 gitlab 、 maven 等等；
第三个是更强大的流水线管理价值流动，层级递进的流水线，输出我们真正的价值。

所以我们选择了开源项目，这个相当于真实的展示项目。这个图是真实的微服务架构，包含了跨语言、分前端、后端、消息队列的场景，基于这个项目实现了我们流水线2.0的方案。

石雪峰：今年818大会上我们发布了2.0架构图，我们也不断的打磨优化了系统架构。架构核心就是基于 Jenkins 构建的三级流水线，包括个人级、提交级的流水线，还有团队级的验证流水线、部署发布流水线。

图左我们采用了 JIRA 进行敏捷项目管理，采用 gitlab 实现代码托管。同时图右在流水线里面我们插接了很多工具，最后在整个基础架构方面采用了容器化的分布式架构平台，多级架构集群设计。接下来我们会基于每一个部分详细的展开我们是如何实现这个架构的。

张乐：我们做了一个模拟项目，双11已经过了，不知道大家有没有赶上，未来可能马上要来圣诞节了。圣诞节我不知道大家要购买什么东西，很多人会说我要买一条袜子，为什么？因为圣诞节会送礼物，大家会把礼物放在新的袜子里面。我们找了一个应用“袜子商店”，用敏捷项目管理方式，管理它的需求。

这个图是用户故事地图的方法，不像传统的敏捷方式只有一个一维的列表，而是变成二维的延展。我们有圣诞节促销、女性购物专场、支付安全等等。我们定义了相关的 story ，现在演示一下，我们对于需求的排期和任务管理的部分。首先可能我是需求的管理人员，会定义马上要到圣诞节了，要做新的用户故事，放在整个用户故事地图里面去。这时候我们开发经理可以看到我们新的任务，并且我们可以从我们任务待办事件列表，拖入到我们待开发的列表中。下面就是看板，也是非常主流的技术，我们可以用看板实现过程中管理我们需求价值的流动。看板里面点开相应的任务，自己选取任务。在开发中状态之后，可以做进一步的操作。

下面是代码纬度里，把需求和代码建立联系，可以基于需求卡片创建一个分支，打开我们的IDE里面，可以做下面功能详细的用户开发。

比如说 feature 里面会增长一些代码，这里面的环节有很多开发人员直接提交代码了，但我们认为不管是 DevOps 也好、实际需求也好，要内检质量。代码提交之前要做好充分的验证工作，比如说这里面展示的要跑一套测试。我们还要做另外一个步骤，就是代码的静态扫描，一两个月之前阿里巴巴发布了 java 的代码规约也被业界接受了，我们也要把它集成在我们IDE工具里面。写完代码之后就用代码规约扫一下里面有多少个问题，比如说这里面扫出了一些需要改进的点，我们要做一些修正。对于代码静态的扫描也是非常关键的，帮助我们找一些关键的陷井出来。还有一个功能是我们IDE和 swagger 做的集成， swagger 集成以后，打开API文档，看看代码和文档是否正确，如果代码和文档本地正确了，有了测试和代码扫描，下一步可以真正做一个事情，就是把代码提交到我们的代码仓库里面。代码要 commit ，然后把代码提交到远程仓库里面去，所有的东西都是被集成好的，选择了 post 命令以后，我们看到代码已经进入到代码库里面去。

景韵：提交完代码之后我们会自动触发个人级的流水线，要快速获取反馈，提交是否破坏了构建，进入到 gitlab 当中，通过第一行目录提交的记录，可以进入到里面。

石雪峰：当我们提交核录代码之后，会有所有的代码牵出、编译、代码测试等一系列的构建环节，最终完成。测试同学验收之后，整个部署到我们测试环境里面。测试同学可以进行手工测试或者探测性测试的工作。测试同学认为改动已经符合我们测试质量要求的话，可以采用交互式按钮，继续流水线扭转，一直扭转到准生产环境的环节。当我们手工认为可以部署到预发布环境的时候，同样的操作，通过点击一个按钮，就可以实现自动化把我们所有环境部署到准生产环境里面去，大家可以欣赏一下这个漂亮的流水线。

张乐：流水线过程一定是逐级验证的，我们说分层分级的目的就是每一步保证代码都是OK的。刚刚景韵演示了我们代码个人级流水线跑一些测试和验证，石雪峰讲了主干上后面相关的操作。如果代码经过了层层的验证，最终的状态就是发布到线上。这里会做一个配置，如果我有权限部署生产环境，执行部署以后就会弹出一个框，选取已经通过流水线的层层验证，被认为是可以发布的产品，比如说这里面会选择某一个0.3.12进行运行。

这里面也强调一个点，作为生产的发布，实际上我们要控制它的质量，经过了再多的测试环节，也有可能在上线、面对生产环境失败。所以我们要用一个很好的实践就是灰度发布，可以按照集群、机器的纬度发布，也可以按照功能 feature 的功能发布。

里面分两个阶段，第一个是只有10%的生产环境被部署，我们做了充分的测试、验证，没有问题之后，我们再发布到百分之百的所有生产环境。

在用户访问到生产环境的时候，背后要做一些监控，这个是每五秒钟做的数据监控。我们可以动态关注KPI和延时，帮助我们提供整个闭环的监控过程。

石雪峰：在探索整个流水线2.0过程中，我们也秉承了一种所谓的极客精神，怎么样把这些业界所谓的新技术还有新实践跟流水线进行结合，跟业务场景进行结合。所以在整个流水线2.0开发过程中，我们采取了很多非常好的优秀实践。

• 第一个就是流水线2.0里面，全面的拥抱容器化。
  
  也就是说我们所有的构建、测试、部署、运行环境全部在容器中进行，通过容器动态化的生成。这一系列的基础就是 Docker in Docker ，按需拉取我们所需的镜像，实现我们的标准环境。

• 第二个是弹性动态集群。
  
  我们把集群全部部署到平台上，实现动态的生成，另外所有的调动资源也同样通过容器调度平台实现，可以实现平台资源统一调动，动态扩容和缩容。

• 第三个流水线工具集成。
  
  在我们流水线里面集成了非常多有用的工具，也是基于用户调查报告，非常欣慰的看到很多主流工具很好的集成到了流水线里面。通过这个流水线打通需求、开发和部署的整个流程。第二个流水线我们不是代替原有的内容，我们要插接部署工具，可以轻松的插入我们的流水线里面来，端到端打通部署的流程。

最后我们还是要说工具和自动化，调查报告当中也提到了，各个环节内部自动化水平还是有待提升。

所以我们流水线里面，演示的环节大家也看到了，除了一些需要认为确认的环节，基本上所有的工作都是通过自动化的方式完成的。通过自动化方式完成的话，也提升了我们整个端到端流水化运行效率。必要的环节同样可以支持这样的人工干预的工作。

景韵：大家看到了这么复杂的一套流水线，所以我们在社区邀请了很多专家和我们一块做这件事情。我们的团队的缩写叫 JPEG ，是希望给大家方向和信心，给大家参考，大家可以基于这套流水线定制自己在公司内部的实践方案。

同时我们也非常欢迎更多的 Jenkins 资深专家参与到项目当中，一起迭代我们的流水线，希望我们流水线3.0、4.0提供更多的 feature 给大家。