端到端流水线如何驱动DevOps落地

白凡

分享：景韵
编辑：白凡

我叫景韵，现在是在DevOps社区，今天分享的是之前在社区同事努力下做的端到端的流水线，我们认为端到端的流水线才能驱动DevOps的落地。

1. DevOps现状及发展方向

上图是2017年的DevOps年度报告，这四个关键指标用来度量整个公司DevOps能力的基本指标。这四个指标后面会拆分成很多细则。

--- 1. 部署频率高。

1. 高效能比低效能部署高46倍
2. 交付时间缩短440倍
3. 变更失败率降低5倍
4. 故障恢复时间快96倍。

核心体现的就是这个企业高效能组织它的竞争优势可以高于快46倍把应用发到线下，传统企业也可以同样发，但是星期一做完下周五才能发布。对于DevOps星期一上午做完可能中午就能发或者随做随发。

DevOps没有一个明确的定义，2009年提出DevOps的时候是一个活动，后来缩减到DevOps这个单词的时候，没有任何人对它下定义，包括目前最权威的专家也不会对DevOps做更多的定义。

但是企业落地DevOps的时候是需要有边界的，到底哪些事情可以DevOps做哪些事情不能做。是DevOps全软件生命过程中应处的阶段这上面DevOps，DevOps处在一个持续延展的过程中，它在不断的进化，这就是持续改进的基本思路。不是一个固定的一种模式，它在不断的发展。从一开始只是运维关注不断的往前延伸，延伸到纳入到持续交付这里边，然后继续往前延伸把敏捷很多相关能力和知识也都纳入其中。甚至再继续往前推进，到我们的业务层，所以现在很多人提出一个单词叫BS DevOps，这就是整个DevOps在阶段中整个生命周期中它的涉及非常广从产品到架构设计，到开发、测试、运维大家都是在整个DevOps中。涉及到这么多角色，到底怎么做都是非常麻烦的，很多人说打破部门墙，这是在敏捷交付里面让大家写单元测试一样难。

做DevOps，上来之后做大量的部门墙打破，依然是会面临很多压力和会造成很多误区。从DevOps这么大的目标这么多事要去做，站在这儿我到达彼岸到底怎么走？中间有很多坑和很多事情要去做。

2. 企业级DevOps理论与实践体系

上图这是刚刚发布的标准，通过这个标准来去界定人为的DevOps它应该包含什么样的内容。

这个标准当中，只看第一级相当于研发运营一体化过程，核心包括敏捷开发管理，持续交付和技术运营。这里面涉及到开发测试和工程能力和技术营运，都在这个纬度中。

3. 流水线驱动DevOps

今天讲的是流水线，它在哪个位置，按照原有的定义它主要在持续交付领域，现有的定义是，为什么我们要叫它端到端，端到端是完整的，从需求开始发布到线上交付到用户手中，是一个完整的过程。要做一个流水线的解决方案，完全是基于开源的提供给大家直接访问做自己内部的内容。

3.1 为什么要做流水线？

1. 价值流动的过程。因为流水线过程中体现的就是需求，流动到用户手中全过程，是驱动DevOps全流程价值流动的过程。
2. 工具整合。研发有自己的工具，测试也有自己的工具，很多有测试的自动化工具，运维有自己的部署工具和监控工具，甚至有SaaS、IaaS层的监控平台，怎么把它们串起来，需要有一个流水线去完成使命。不是通过文档方式让大家使用，还是需要中间有一个平台，这个平台可以集成大家。有个东西在企业当中架构层面它处在一个串起来过程中，同样在流水线地位也是一样，需要串起来各自有各自的业务，各自有自己的领域自己的实践，通过流水线把它串起来。
3. 实现质量门的控制。不是说在DevOps模式下大家跑的很快，死的也很快，在流水线中一定要定义好质量部门，这样才能把测试能力嵌入进去。最后通过流水线可以很好的达到可视化整个状态，帮助我们度量改进。因为这个流水线上有大量的数据都在这个层面、软件研发过程、交付过程、测试、运营过程中所有的数据都可以在这个过程中体现。

3.2 流水线调研结论

上图调研报告总结了几个关键技术点。

1. 交付频率要求提高。由65%的受访者每周一次以上的部署频率，这充分说明国内IT企业，至少说参与调查的IT企业，公司能力已经是在很大的台阶之上，部署频率和成功率正相关，部署频率越高部署成功率越高。64%是已经实现持续交付流水线的，其中86%的在使用Jenkins做支撑。各阶段工具与流水线集成比例低于25%，我们希望各阶段工具跟流水线有一个更完整的集成，可以通过更多的自动化能力把这个固化进去。现在集成很困难，所以首先需要做到端到端的整合，以及多工具之间的集成。
2. 自动化触发比例比较低。我们需要做到代码提交自动触发，很多团队已经在这条路上，流水线的支撑分级，一会儿看怎么做到的。在很多团队中，包括代码扫描、非功能测试、灰度发布、分布式配置中心、数据库变更管理使用都不够全面，相对来说少一些。

基于这些结论，我们继续完善得到了这样的一张图——流水线2.0整体架构设计。今天再详细解释一下这张图的具体逻辑。

• 从图中列来看，第一列是需求、任务、代码。
• 第二列就是全自动流水线的过程。第二列相当于定义四个流水线阶段，第一个提交阶段，第二个验收阶段，第三个是发布阶段的部署，最后是生产环境的部署。
• 同时把右侧第三列，大部分开源工具集成到流水线中，这样开放能力通过流水线体现出来。
• 最后一列是跟技术运营相关的，之前整个Dome是基于Kubernetes做的，包括之前参加一些会议的时候有明确反馈，在国外社区Kubernetes完全是一种天下了。

需求出来之后基于用户去创建分支，分支创建出来之后在本地做代码修改实现需求，然后代码提交上来。这时候提交只要提交到分支会自动分发，验收流水线，这是最简单的代码扫描，这要有一个基础，你的库拆的足够小，如果非常大的话，不建议做扫描工作，因为做代码扫描主流工具是比较重量工具，会把元代码写出来，生成一个数据库耗时很多。

结束之后会有反馈，到底有没有破坏边缘测试，这时候开发人员再发起一个MESOS，使用Kubernetes进行强制代码审查。对大部分公司目前来讲还是一个比较难做的事情，所以我们一直强调小批量做Review，只要从今天开始技术债不再往上增加，比如潜在BUG和重复率这些指标不能持续恶化，所以诞生了一个要求：这次提交代码导致比例升高，提交直接驳回，你需要去改。
接受这次代码合并之后，会触发整个验收，这很复杂，要打包镜像，镜像Push镜像仓库，开源主要以HAPBOR为主，它包括多个项目，我们也会在物理上做隔离，然后做自动化的手工测试，同时在代码库中打一些Tag，这样测试部署的时候我们从仓库中把镜像版本获取下来。同样发布到预发布环境，通过HAPBOR去获取。同一个镜像有一个统一原则叫HHOT，是单一制品原则，就是说所有的内容都是要构建出来一次镜像版本，不能在不同的环境反复构建，因为包可能不一致。

3.3 微服务项目实例

WEAVEWORKS有一个微服务的项目叫袜子商店。这个项目部算是非常典型意义上的微服务项目，但是前端依然有很多的分离。
大家以前做微服务主要是用于微商可以理解，而且关系型数据库和非关系型数据库都可以用，这个过程中使用了Jira去实现。简单看一下这个实例长什么样子：

这是一个友好的商业工具，大量企业已经使用这样的工具做需求相关的管理。

首先是用户故事的地图，基于袜子商店做的一个具体的用户拆分，分为不同的场景，不同的场景里有具体每一个单个用户故事，需要跟场景对应起来结合左上角版本，可以看到用户故事的全貌，这个版本中发哪些产品，也是帮助产品经理识别哪些产品要去做。当需要做圣诞节促销例子的时候，可以把最下面具体的用户故事拖拽到上面，在这个上面把具体的需求拽上去，纳入这个版本做迭代计划会议之前做需求定义的时候拽到上面，然后有一个看板，在看板中可以看具体的任务，进行准备拖拽。

分配后进入到下一个级别IDE，下拉出来我的任务及基于这个任务会牵出一个代码，

这时候牵出一个分支，分支名称也不需要我们重新定义规范，按照标准走，提交代码一定是提交到分支上，所以直接提交到这个分支上，大家可以看到右上角，我提交的新的代码，后面有一个绿色的标注，这是我提交的流水线经过了验证，然后返回结果，通过了单元测试和代码扫描，这次提交没问题，这就是持续集成最基本的理念。

这是验收阶段的整个流水线。
这里具体步骤值得大家学习和参考。第一先去代码编译，做代码质量层面的，包括总编辑的测试，包括never的测试，生成文档，写好接口的参数，生成API文档，这样同时做API对接的时候不要给我一大堆API文档给我一个API在线官网就可以测试完之后把镜像Push到仓库，等待部署。如果大家没有用过Jenkins的话，强烈大家使用，而且2.0新的功能是我们可以做一些人工介入。

有人提过一个问题，出这么多版本，我的测试换部署，让测试怎么测，所以这时候一定需要人工干预，就是测试想测的情况下自己可以点流水线，我们把包打出来部署完，这样相对来讲是一个测试驱动交互的过程，而不是我们给它推包。如果我们按照一定节奏去做的话，每天做一次，或者每天做两次都是可以的。上次我们说过去浙江移动做评估，他们一天有三到四次测试环境的过程。

部署时可以选择不同的版本，这个演示我们有一个理念传递给大家，部署是一个高风险动作，发布更加是高风险动作，部署会破坏我们的环境导致服务不可用，发布可能导致对现有的不可用，部署一定要独立，所以才有灰度的这种方式，我们先把它部署上去，相当于我们部署的方式可以有灰度，发布的时候同样有少量的用户去做这样的事情，这些都是为了降低我们的风险。

最后就是整个袜子商店我们部署完的效果，这里简单做成了一个监控，相当于线上看有没有人访问，更新完之后有没有流量进来，都可以在这上面看到。

4. 全面拥抱容器化

核心通过容器化的方式把它给做起来，所有东西都在容器里面，包括构建，都在容器利用测试也在容器里面，部署的脚本也在容器里面，包括Kubernetes也在容器里面。

弹性动集群说的是，整个Jenkins是动态的，很多用Jenkins的时候都是单个虚拟机跑，这是紫云浪费，所以通过Kubernetes集成，这就是端到端打通的过程。

流水线的16个特性包括版本控制、最优分支策略、代码静态扫描、80%以上单元测试覆盖率、漏洞嫂、制品管理、开源工具扫描、环境自动化创建、不可变基础设施、集成测试、性能测试、自动化变更请求、功能开关、60%以上自动化接口测试覆盖率、零停机发布。

Value Stream Mapping《持续交付》这本书对整个软件交付非常重要。书第一章讲的是价值流行色，是缺陷被发现到被修复经历的环节，哪些环节需要等待，哪些环节有识之性的工作，这就是惊异敏捷的周期时间、前置时间等等，这个过程中上面只有整个方块是有价值的。

比如说第三个方块是说开发修复这个BUG，但是修复的时候等了16个小时，2天才去修复。包括后面准备环境准备8个小时，才进行测试，这些都是低自动化的表现。

这个过程中我们可以衡量到，当中的三角形的时间，加上整个方块的时间，就知道总体时间是多长了。方块时间除上整体时间等于时间利用率，这个项目大概28%左右，数据经验显示能超过30%的不多。

5. Jenkins 下一代发展

可以说Jenkins下一个产品的东西叫Jenkins-S，是一套为了微服务，为了将来跑应用做的一个平台。这个图是Jenkins的逻辑设计图，跟我们流水线的那个一模一样。

这套流水线的方案我们自己的尝试，希望给大家一些方向和引导。我们计划6月29号北京会做一次DevOps国际峰会，那个会场上大概还有三个月左右的时间，会把刚才所有讲的这套方案去开放，包括很多脚本怎么写的，工具之间集成怎么配置，等等功能都会开放出来。如果当中有一些工具的封装都希望开源出来希望更多的人受益，因为毕竟它是开源的内容，我们也要遵循开源的理念。所有内容就是这些，谢谢大家！